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Preface 


This book provides a complete language reference for the expert C++ user. It 
consists of the C++ reference manual plus annotations and commentary 
sections. 

The C++ reference manual alone provides a complete definition of C++, 
but the terse reference manual style leaves many reasonable questions 
unanswered. Discussions of what is not in the language, why certain features 
are defined as they are, and how one might implement some particular 
feature have no place in a reference manual but are nevertheless of interest to 
most users. Such discussions are presented as annotations and in the 
commentary sections. 

The commentary also helps the reader appreciate the relationships among 
different parts of the language and emphasizes points and implications that 
might have been overlooked in the reference manual itself. Examples and 
comparisons with C also make this book more approachable than the bare 
reference manual. 

This book does not provide information about standard libraries beyond 
discussion of the library functions providing the most basic run-time support 
nor does it discuss C++ programming styles or techniques. Furthermore, this 
book does not attempt to teach C++ programming; it explains what the 
language is - not how to use it. 

The index and the cross references embedded in the commentary and in 


the reference manual itself are important and integral parts of the book. 


We hope that this reference manual will provide a firm base for the further 
evolution of C++. It has been chosen by ANSI to serve as a starting point for 
the formal standardization of C++. 


Murray Hill, New Jersey, Margaret A. Ellis and Bjarne Stroustrup 


Organization 


The C++ reference manual consists of 16 major sections and two appendices 
each of which is used as the nucleus of a chapter of this book. The C++ 
reference manual proper is presented in 10 point Times Roman font. 
Embedded annotations are presented in 
9 point Times Roman font 
indented and bracketed, as this sentence is. 
Examples in the manual proper are presented using a constant width font: 
int a; // manual example 
An italicized constant width font is used for examples in the commentary: 
int b; // commentary example 
Major discussions are placed after the manual sections. Thus, each 
chapter consists of an abstract followed by an annotated manual section 


optionally followed by a commentary section. The heading 


COMMENTARY 
separates the manual and the commentary parts of a chapter. 
Commentary subsections contain the suffix `c' to distinguish them from 
reference manual sections. Except for the chapter prefix, the numbering of 
commentary sections is unrelated to the section numbering of the manual 


proper. 
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Introduction 


This chapter contains the introductory section of the C+ reference manual and 
demonstrates the mechanisms for presenting commentary to the reference manual 
proper. The commentary section summarizes the evolution of the C+ program- 
ming language and lists the people who took part in the 1989 reviews of the C+ 
reference manual. 


1 Introduction 


This manual describes the CH- programming language as of February 1990. C+ is 
a general purpose programming language based on the C programming language*. 
In addition to the facilities provided by C, G+ provides classes, inline functions, 
operator overloading, function name overloading, constant types, references, free 
store management operators, and function argument checking and type conversion. 
These extensions to C are summarized in §18.1. The differences between CH and 
ANSI CÌ are summarized in §18.2. The extensions to CH since the 1985 edition 
of this manual are summarized in §18.1.2. The sections related to templates ($14) 
and exception handling (§15) are placeholders for planned language extensions. 


m The pre-ANSI C dialects based on K&R plus structure assignment and enumera- 
tions will be collectively referred to as **Classic C.’’ The adjectives **Classic’’ and 
“ANSI” will be used only where differences exist between Classic C and ANSI C. 
Most often, the name C will be used without an adjective. O 


* “The C Programming Language’* by Brian W. Kemighan and Dennis M. Ritchie, Prentice Hall, 1978 
and 1988. 
t American National Standard X3.159-1989. 
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1.1 Overview 


This manual is organized like this: 


1. Introduction 10. Derived Classes 

2. Lexical Conventions 11. Member Access Control 

3. Basic Concepts 12. Special Member Functions 

4. Standard Conversions 13. Overloading 

5. Expressions 14. Templates (experimental) 

6. Statements 15. Exception Handling (experimental) 
7. Declarations 16. Preprocessing 

8. Declarators Appendix A: Grammar Summary 
9. Classes Appendix B: Compatibility 


1.2 Syntax Notation 


In the syntax notation used in this manual, syntactic categories are indicated by 
italic type, and literal words and characters in constant width type. Alterna- 
tives are listed on separate lines except in a few cases where a long set of altema- 
tives is presented on one line, marked by the phrase ‘‘one of.’ An optional termi- 
nal or nonterminal symbol is indicated by the subscript ‘‘opt,’’ so 


{ expression,,, } 


indicates an optional expression enclosed in braces. 





Commentary 


llc Evolution of C+ 


In 1980, classes, function argument type checking and conversion, and a few other 
features were added to C; the resulting language was called ‘'C with Classes.” 
This language was described in Bjarne Stroustrup: ‘‘Classes: An Abstract Data 
Type Facility for the C Language,’ ACM SIGPLAN Notices Vol 17, no 1, January 
1982 and in-Bjarne Stroustrup: ‘‘Adding Classes to C: An Exercise in Language 
Evolution,” Software — Practice & Experience, Vol 13 (1983). 

In 1983/84, C with Classes was redesigned, extended, and reimplemented; the 
resulting language was called GH. The major extensions were virtual functions and 
operator overloading. Ct was first described in Bjame Stroustrup: ‘Data Abstrac- 
tion in C,’’ AT&T Bell Laboratories Technical Journal Vol 63, No 8, October 
1984, After a few further refinements, CH became generally available in 1985 and 
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was documented by Bjarne Stroustrup’s book ‘The C+ Programming Language,“ 
Addison Wesley 1986. 

This manual documents C+ as it now exists after the addition of support for 
multiple inheritance, type-safe linkage, abstract classes, refined mechanisms for 
overloading resolution, and other enhancements; see Chapter 18 for details. In 
addition, commentary sections present two proposed extensions of CH: templates 
(Chapter 14) and exception handling (Chapter 15). 

Since its conception, C+ has been evolving to meet the needs of its users. The 
experience of users of diverse backgrounds working in a wide range of applications 
has guided this evolution. 

Because C+ has been in use for large software projects, stability and compati- 
bility have been important considerations in the development of the language; so 
has run-time and space efficiency. Time and space overheads above those for C 
are considered unacceptable for C+. 

The primary aim in extending CŒ} has been to enhance it as a language for data 
abstraction and object-oriented programming in general and as a tool for writing 
high quality libraries in particular. 

Portability of at least some C+ implementations has been a key design goal, so 
extensions that would add significantly to the time required to port a CH imple- 
mentation or to the demands on system resources by a CH compiler have been 
avoided. 


1.2c Acknowledgements 


The February 1990 C+ reference manual was written by Bjame Stroustrup helped 
by an extensive review of several drafts. Many dozens of people were involved in 
this review and their contributions were invaluable. We do not know the names of 
everyone involved. In particular, several reviews are clearly the work of a group of 
people but contain only the name of a single individual and the name of an organi- 
zation. The following, however, is the most complete list we have been able to 
compile. The list is sorted by affiliation and affiliations apply to the immediately 
preceding sublist of people. The affiliation of an individual is the affiliation at the 
time the review was written. 

James Waldo (Apollo Computer Inc.), Ken Friedenbach (Apple), Mark Behm, 
Dave Brand, Phil Brown, Steve Buroff, Jim Coplien, Edna Edelman, Moshe Eliov- 
son, Margaret Ellis, Roselle Femandez, Doug Gibbons, Georges Gonthier, Tony 
Hansen, Bill Hopkins, Stacey Keenan, Andrew Koenig, Doug Mclllroy, Brian Ker- 
nighan, Stan Lippman, Bill Mershon, Dave Prosser, Margaret Quinn, Johnathan 
Shopiro, Kathy Stark, Peter Weinberger (AT&T), Craig Bordelon, Joe Carfagno, 
Steve Carter, Bill Donahue, Stu Feldman, Wen-Yau Hsieh, Eric Krohn, Paul 
Matthews, Linda Schumacher (Bellcore), Michael B. Jones (Camegie-Mellon 
University), Roger Scott (Data General), Donald Courtney, George Hetrick, Gary 
Pollice, Craig Hansen-Sturm, Laura Yaker (DEC), Steve Dewhurst (Glockenspiel), 
Timothy C. O’Konski, Mark Mathieu, Kathy Harris, Rob Seliger, Dmitry Lenkov, 
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Parag Patel, Nancy Sechrist, Paul Faust (Hewlett Packard), John J. Barton, Derek 
Lieber, Lee Nackman (IBM), Marc Shopiro (INRIA), Jesper Boelsmand (Jensen & 
Partners Inc.), Ron Guilmette (MCC), Jim Howard, Archie Lachner (Mentor Graph- 
ics), Tom Davies, Mitch Harter, Ross Garmoe, Jan Gray, David Jones, Jonathan 
Kimmich, Martin O'Riordan, Scott Randell, Tony Williams, Craig Wittenberg 
(Microsoft), Sam Haradhvala (Object Design Inc.), Mike Mowbray (Overseas 
Telecommunications Commission, Australia), Phillipe Gautron (Rank Xerox France 
& LITP University of Paris VI), William Bulley (Schlumberger), Prescott K. 
Tumer, Jr., William M. Miller, Michael J. Young (Software Development Techno- 
logies Inc.), Mark Linton, Michael Tiemann, Craig Chambers (Stanford University), 
Lily Chang (Sun Microsystems), Michael S. Ball, Stephen D. Clamage (TauMetric 
Corporation), Mark Rafter, Steve Rumsby (University of Warwick), Walter Bright 
(Zortech, Inc.), John M. Dlugosz, James Roskind. 

C+ owes much to their efforts. Naturally, these people are in no way responsi- 
ble for mistakes in the manual and naturally they made many suggestions for 
improvements that could not be accommodated for lack of time, because of compa- 
tibility issues, or for other reasons. 














Lexical Conventions 


This chapter presents the lexical conventions of C+. It defines tokens in a C+ 
program and describes comments, identifiers, keywords, and literals — integer, 
character, and floating point constants and string literals. Operators are dis- 
cussed in §5. The C+ grammar based on these token is summarized in §17. 


2 Lexical Conventions 


A CH program consists of one or more files (§3.3). A file is conceptually 
translated in several phases. 


m A file is a piece of text containing C+ source code and preprocessor commands. 
In other words, it is a source file on a traditional system. Dedicated C+ environ- 
ments may have more elaborate ways of storing a file in a program data base. O 


The first phase is preprocessing (§16), which performs file inclusion and macro 
substitution. Preprocessing is controlled by directives introduced by lines having # 
as the first character other than white space (§2.1). The result of preprocessing is a 
sequence of tokens. Such a sequence a tokens, that is, a file after preprocessing is 
called a translation unit. 


m Except for the treatment of C+ // comments and C+ tokens that are not also C 
tokens (. *, —>*, and ::), Ch preprocessing is ANSI C preprocessing. Onginally, 
Classic C style preprocessors were used for CH, but the current definition of C+ 
preprocessing (§16) conforms to ANSI C preprocessing. O 


2.1 Tokens 


There are five kinds of tokens: identifiers, keywords, literals, operators, and other 
separators. Blanks, horizontal and vertical tabs, newlines, formfeeds, and com- 
ments (collectively, ‘white space”), as described below, are ignored except as they 
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serve to separate tokens. Some white space is required to separate otherwise adja- 
cent identifiers, keywords, and constants. 

If the input stream has been parsed into tokens up to a given character, the next 
token is taken to be the longest string of characters that could possibly constitute a 
token. 


2.2 Comments 


The characters /* start a comment, which terminates with the characters */. 
These comments do not nest. The characters // start a comment, which terminates 
at the end of the line on which they occur. The comment characters //, /*, and 
*/ have no special meaning within a // comment and are treated just like other 
characters. Similarly, the comment characters // and /* have no special meaning 
within a /* comment. 


m There are rare code sequences for which the CH // commenting convention will 
cause C+#+’s interpretation of a program fragment to differ from C’s interpretation of 
the same fragment. Consider 


int b = a//* divide by 4 */4; 
-a; 


With comments deleted, C+ parses this as 
int b =a -a; 
while C sees the same construct as 


int b = a/4; -a; 


2.3 Identifiers 


An identifier is an arbitrarily long sequence of letters and digits. The first character 
must be a letter; the underscore _ counts as a letter. Upper- and lower-case letters 
are different. All characters are significant. 


m CH sets no maximum length for an identifier. Some implementations impose con- 
straints on the length of identifiers. This is unfortunate and makes it harder for users 
of such systems to import software and to adhere to common naming conventions. 
It is, however, sometimes infeasible to upgrade basic system software and given the 
choice between accepting a limitation and not using CH the limitation is often 
accepted, Similarly, experience shows that if (and only if) no alternative exists users 
will accept an implementation that is unable to distinguish upper-case from lower- 
case letters in extemal names. O 
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2.4 Keywords 


Keywords 7 


The following identifiers are reserved for use as keywords, and may not be used 


otherwise: 
asm continue float new signed try 
auto default for operator sizeof typedef 
break delete friend private static union 
case do goto protected struct unsigned 
catch double if public switch virtual 
char else inline register template void 
class enum int return this volatile 
const extern long short throw while 


In addition, identifiers containing a double underscore (_ _) are reserved for use 
by C+ implementations and standard libraries and should be avoided by users. 


m Identifiers starting with a single underscore (_) should also be avoided by ordinary 
users since C implementations reserve those for their own use. O 


The ASCII representation of C+ programs uses the following characters as 
operators or for punctuation: 


=. 455 —— z <= >= == l= && 
Il t= /= t= += -= <<= >>= c= Asx = “rs 


Each is a single token. 
In addition, the following tokens are used by the preprocessor: 


# H 


Certain implementation-dependent properties, such as the type of a sizeof 
(§5.3.2) and the ranges of fundamental types (§3.6.1), are defined in the standard 
header files ($16.4) 


<float.h> <limits.h> <stddef.h> 


These headers are part of the ANSI C standard. In addition the headers 
<stdlib.h> 


<new.h> <stdarg.h> 


define the types of the most basic library functions. The last two headers are part 
of the ANSI C standard; <new.h> is C+ specific. 
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@ Naturally, many other libraries and their associated header files will be available to 
the CH programmer. For example, 


<stdio.h> <iostream.h> <string.h> 


These, however, do not affect the semantics of the language and are therefore not 
Specified here. O 


2.5 Literals 


There are several kinds of literals (often referred to as ‘‘constants’’). 


literal: 
integer-constant 
character-constant 
floating-constant 
String-literal 


2.5.1 Integer Constants 


An integer constant consisting of a sequence of digits is taken to be decimal (base 
ten) unless it begins with 0 (digit zero). A sequence of digits starting with O is 
taken to be an octal integer (base eight). The digits 8 and 9 are not octal digits. A 
sequence of digits preceded by Ox or OX is taken to be a hexadecimal integer (base 
sixteen), The hexadecimal digits include a or A through f or F with decimal 
values ten through fifteen. For example, the number twelve can be written 12, 
014, or 0XC. 

The type of an integer constant depends on its form, value, and suffix. If it is 
decimal and has no suffix, it has the first of these types in which its value can be 
represented: int, long int, unsigned long int. If it is octal or hexa- 
decimal and has no suffix, it has the first of these types in which its value can be 
represented: int, unsigned int, long int, unsigned long int. If it is 
suffixed by u or U, its type is the first of these types in which its value can be 
represented: unsigned int, unsigned long int. If it is suffixed by 1 or L, 
its type is the first of these types in which its value can be represented: long int, 
unsigned long int. If it is suffixed by ul, lu, uL, Lu, Ul, 1U, UL, or LU, 
its type is unsigned long int. 


m For example, 100000 is of type int on a machine with 32 bit ints, but of type 
long int ona machine with 16 bit ints and 32 bit longs. Similarly, OXA000 is 
of type int on a machine with 32 bit ints, but of type unsigned int ona 
machine with 16 bit ints. These implementation dependencies can usually be 
avoided by using suffixes: 100000L is long int on all machines and OXAQ00U 
is of type unsigned int on machines with at least 16 bits for an unsigned 
int. O 
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2.5.2 Character Constants 


A character constant is one or more characters enclosed in single quotes, as in ’ x’. 
Single character constants have type char. The value of a single character con- 
stant is the numerical value of the character in the machine's character set. 


m In C, all character constants are of type int. Interestingly enough, having single 
character constants as type char in C+ does not cause compatibility problems. In 
C, the int value of the character constant is obtained by taking a char value and 
promoting it to an int. This is exactly what C} will do in all contexts where 
integral promotion (§4.1) occurs. There is only one place in C where a character 
constant does not suffer integral promotion and consequently only one place where 
the difference in the type of a character constant can be detected in a program that is 
both legal C and C+: sizeof(’a’) has the value 1 in C+ and a value 
sizeof (int) inC. 

In C+, however, having character constants of type char is important because 
of overloading; it allows functions to distinguish between small integers and charac- 
ters; see §13.2. O 


Multicharacter constants have type int. The value of a multicharacter constant is 
implementation dependent. 


m For example, the value of 
ABS 


could reasonably expected to be ’A’ ’B’ and (’A’<<8)+’B’ on three different 
implementations. Multicharacter constants are usually best avoided. 0 


Certain nongraphic characters, the single quote ‘, the double quote ", the ques- 
tion mark ?, and the backslash \, may be represented according to the following 
table of escape sequences: 


new-line NL (LF) \n 


horizontal tab HT \t 
vertical tab VT \v 
backspace BS \b 
carriage retum CR \r 
form feed FF \£ 
alen BEL \a 
backslash \ \\ 
question mark ? \2 
single quote J We 
double quote te We 
octal number 000 \oo0o 
hex number hhh \xhhh 


If the character following a backslash is not one of those specified, the behavior is 
undefined. 
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@ This differs from the interpretation by Classic C and early versions of CH, where 
the value of a sequence of a backslash followed by a character in the source charac- 
ter set, if not defined as an escape sequence, was equal to the numeric value of the 
character, For example, ’\q’ would equal ’q’. O 


An escape sequence specifies a single character. 

The escape \ooo consists of the backslash followed by one, two, or three octal 
digits that are taken to specify the value of the desired character. The escape 
\xhhh consists of the backslash followed by x followed by a sequence of 
hexadecimal digits that are taken to specify the value of the desired character. 
There is no limit to the number of hexadecimal digits in the sequence. A sequence 
of octal or hexadecimal digits is terminated by the first character that is not an octal 
digit or a hexadecimal digit, respectively. The value of a character constant is 
implementation dependent if it exceeds that of the largest char. 

A character constant immediately preceded by the letter L, for example, L’ ab’, 
is a wide-character constant. A wide-character constant is of type wchar_t, an 
integral type (§3.6.1) defined in the standard header <stddef.h>. Wide- 
characters are intended for character sets where a character does not fit into a single 
byte. 


2.5.3 Floating Constants 


A floating constant consists of an integer part, a decimal point, a fraction part, an e 
or E, an optionally signed integer exponent, and an optional type suffix. The 
integer and fraction parts both consist of a sequence of decimal (base ten) digits. 
Either the integer part or the fraction part (not both) may be missing; either the 
decimal point or the letter e (or E) and the exponent (not both) may be missing. 
The type of a floating constant is double unless explicitly specified by a suffix. 
The suffixes f and F specify float, the suffixes 1 and L specify long double. 


m For example, 2.0, 2., 0.2e1, and .2E1 are doubles, 2.0F and 20e-1F are 
floats, and 2.0L is a long double. O 


2.5.4 String Literals 


A string literal is a sequence of characters (as defined in §2.5.2) surrounded by 
double quotes, as in "...". A string has type ‘‘array of char’ and storage class 
Static (§3.5), and is initialized with the given characters. Whether all string literals 
are distinct (that is, are stored in nonoverlapping objects) is implementation depen- 
dent. The effect of attempting to modify a string literal is undefined. 

Adjacent string literals are concatenated. Characters in concatenated strings are 
kept distinct. For example, 


” \ xA" "pu 


contains the two characters ‘\\xA’ and ’B’ after concatenation (and not the single 
hexadecimal character ’ \xAB’ ). 
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After any necessary concatenation ’\0’ is appended so that programs that scan 
a string can find its end. The size of a string is the number of its characters includ- 
ing this terminator. Within a string, the double quote character " must be preceded 
by a \. 

A string literal immediately preceded by the letter L, for example, L"asd£", is 
a wide-character string. A wide-character string is of type ‘‘array of wchar t,” 
where wchar t is an integral type defined in the standard header <stddef .h>. 
Concatenation of ordinary and wide-character string literals is undefined. 


E Given the two declarations 


char’ strl = "Please enter name and address"; 
char* str2 = "name and address"; 


some implementations will create two nonoverlapping memory locations containing 
the string literals, while others will optimize the use of memory by initializing str2 
to point to the substring "name and address" within the string pointed to by 
stri. 

This implies that string literals are best treated as constants by the programmer 
since modifying one string may modify another string that may not even be known 
to the programmer. For example, the second — unintentionally modified — string 
might be part of a standard library linked to the program. 

String literals are of type char{] (see §2.5.4) and not const char[] for 
compatibility with Classic C where early software took advantage of string literals 
being distinct and modifiable. O 








Commentary 





2.1c Implementation Dependencies 


Like C, CH leaves many details ‘‘implementation-dependent.’’ This is done partly 
to allow an implementation to take maximum advantage of the hardware (for exam- 
ple, the sign of the result of a % operation with a negative argument, §5.6), and 
partly to allow the programmer to manipulate the hardware directly rather than an 
implementation independent abstract machine. There are about thirty 
implementation-dependent features in the C++ language (the exact number depends 
on exactly what one considers separate features); they can be found by looking up 
‘implementation dependency”’ in the index. 

Clearly, use of implementation-dependent features can lead to portability prob- 
lems. Consequently, the documentation for an implementation should provide a 
detailed explanation of the choices made for each implementation-dependent 
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feature. In addition, tools that detect reliance on implementation-dependent features 
can be very useful. 

Why couldn’t CH have resolved these implementation dependencies by defining 
a right answer for each? The reason is partly that some implementation dependen- 
cies are necessary to retain the closeness to the machine that allows C and CH to 
serve for low-level systems programming and allows an implementation to use the 
full speed of a machine's arithmetic unit and memory access hardware. Another 
reason is that resolving such things in CH but not in C would make it highly 
unlikely that compatible C and CH implementations would be provided for a given 
system, thereby creating a whole new class of subtle compatibility and portability 
bugs. 


—— 














Basic Concepts 


This chapter presents the basic concepts of the C+ language. It explains the 
difference between an object and a name and how they relate to the notion of an 
Ivalue. It introduces the concepts of a declaration and a definition and presents 
C's notion of Mpe, scope, linkage, and storage class. The mechanisms for 
starting and terminating a program are discussed. Finally, this chapter presents 
the fundamental types of the language and lists the ways of constructing derived 
types from these. 


This chapter does not cover concepts that affect only a single part of the 
language. Such concepts are discussed in the relevant chapters. 


3 Basic Concepts 


A name denotes an object, a function, a set of functions, an enumerator, a type, a 
class member, a template, a value, or a label. A name is introduced into a program 
by a declaration. A name can be used only within a region of program text called 
its scope. A name has a type, which determines its use. A name used in more 
than one translation unit may (or may not) refer to the same object, function, type, 
template, or value in these translation units depending on the linkage (§3.3) speci- 
fied in the translation units. 

An object is a region of storage (§3.7). A named object has a storage class 
(§3.5) that determines its lifetime. The meaning of the values found in an object is 
determined by the type of the expression used to access it. 


3.1 Declarations and Definitions 


A declaration (§7) introduces one or more names into a program. A declaration is 
a definition unless it declares a function without specifying the body ($8.3), it con- 
tains the extern specifier ($7.1.1) and no initializer or function body, it is the 
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declaration of a static data member in a class declaration (§9.4), it is a class name 


declaration (§9.1), or it is a typedef declaration (§7.1.3). The following, for exam- 
ple, are definitions: 


int a; 

extern const c = 1; 

int f(int x) { return xta; } 
struct’ S { int a; int b; }; 
enum { up, down ); 


whereas these are just declarations: 


extern int a; 
extern const c; 
int f (int); 
Struct: S; 
typedef int Int; 


There must be exactly one definition of each object, function, class, and 
enumerator used in a program (§3.1). If a function is never called and its address 
is never taken, it need not be defined. Similarly, if the name of a class is used 


only in a way that does not require its definition to be known, it need not be 
defined. 


m Note that declarations can be repeated whereas definitions cannot. For example, 


struct S; 

struct S; // OK: redeclaration 
typedef int Int; 

typedef int Int; // OK: redeclaration 
int a; 

int a; // error: redefinition 


extern const c 1; 
extern const c = 1; // error: redefinition 


i 


The general model is that there must be exactly one definition of each object, func- 
tion, class, and so on in a program, whereas there can be as many declarations as is 
desired. 

Note that CH differs from ANSI C by considering int a;*’ (with no extern 
specifier) a definition. The reason for this is partly to ensure that there is no differ- 
ence between saying “int a;*' twice in a single translation unit and “int a;” 
twice in two separate translation units; partly to avoid having different rules for 
built-in and user-defined (§9) types . Consider 


class Int { /* ... */ public: Int(); h; 
Int a; 
Int a; // error: two definitions of ‘a’ 


Here, both occurrences of 
Int a; 


are clearly definitions because a call of the constructor Int: :Int () is required for 
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each. The statement 
int a; 
is considered equivalent to = 


Int a; 


except for the difference in type and is considered exactly equivalent to 


int a = 0; 


3.2 Scopes 


There are four kinds of scope: local, function, file, and class. 


Local: A name declared in a block (§6.3) is local to that block and can be 
used only in it and in blocks enclosed by it after the point of declaration. 
Names of formal arguments for a function are treated as if they were 
declared in the outermost block of that function. 


Function: Labels (§6.1) can be used anywhere in the function in which they 
are declared. Only labels have function scope. 


File: A name declared outside all blocks (§6.3) and classes (§9) has file 
scope and can be used in the translation unit in which it is declared after the 
point of declaration. Names declared with file scope are said to be global. 


Class: The name of a class member is local to its class and can be used 
only in a member function of that class (§9.3), after the . operator applied 
to an object of its class (§$5.2.4) or a class derived from (§10) its class, after 
the -> operator applied to a pointer to an object of its class (§$5.2.4) or a 
class derived from its class, or after the :: scope resolution operator (§5.1) 
applied to the name of its class or a class derived from its class. A name 
first declared by a friend declaration (§11.4) belongs to the global scope; 
the same is true for the name of a class first declared in a retum or argu- 
ment type. 


Special rules apply to names declared in function argument declarations ($8.2.5), 
and friend declarations (§11.4). 


m Note that class and typedef names nest properly within classes. They do not in C 
nor did they previously in G+; see §9.7, §18.3.5. O 


A name may be hidden by an explicit declaration of that same name in an 
enclosed block or in a class. A hidden class member name can still be used when 
it is qualified by its class name using the :: operator ($5.1, §9.4, §10). A hidden 





16 Basic Concepts Chapter 3 


name of an object, function, type, or enumerator with file scope can still be used 
when it is qualified by the unary :: operator (§5.1). In addition, a class name 
(§9.1) may be hidden by the name of an object, function, or enumerator declared in 
the same scope. 


m The operator :: followed by an identifier refers to the object of file scope named 
by that identifier. This allows an object to be visible even if its identifier has been 
hidden. For example, 


int g = 99; 


int f(int g) 
{ 
return g ? g : ::g; // return argument if it 
// is nonzero otherwise 
// return global g 
) 


Similarly, a class name that has been hidden by a nontype name can still be used 
with the :: operator, as follows: 


class X { 

PARE 
public: 

static int xval(); 
j: 


int £(X* p) 
{ 
int X = 44; // hiding the class name 
ES pe 
return X::xval(); // X before :: is a class name 


D 


If a class and an object, function, or enumerator are declared in the same scope (in 
any order) with the same name the class name is hidden. A class name hidden by 
a name of an object, function, or enumerator in local or class scope can still be 
used when appropriately (§7.1.6) prefixed with class, struct, or union. 


E See the commentary (§3.1) for examples of hiding of class names. O 


The scope rules are summarized in §10.4. 
The point of declaration for a name is immediately after its complete declarator 
(§8) and before its initializer (if any). For example, 


int x = 12; 
{ int x = x; } 


Here the second x is initialized with its own (unspecified) value. 


Section 3.2 Scopes 17 


m Consider 


struct s { /*%...*/ }; // declare struct s in file scope 


fi) 

{ 
extern int s(s*); // declare s() in local scope 
s(0); // call s() 

} 


Here, a struct s is declared at file scope. Then a function s () taking a pointer 
to a struct s as its argument is declared at local scope in £(). Because the 
point of declaration of s () in 


extern int s(s*); 


is after the full declarator has been parsed (and the argument type is part of the 
declarator), struct s is still in scope and can be used to specify the type of the 
argument for the function s (). 

Consider also 


int x = 7; 
int f(int x, int y = x); // error 


Here, the point of declaration for the argument x is at the comma, so y's default 
value is the argument x and not the global x; see §8.2.6. Using one argument as the 
default value for another happens to be illegal (§8.2.6). O 


The point of declaration for an enumerator is immediately after the identifier 
that names it. For example, 


int x = 12; 
enum { x = x }; 


Here, again, the enumerator x is initialized to its own (uninitialized) value. 


3.3 Program and Linkage 


A program consists of one or more files (§2) linked together. A file consists of a 
sequence of declarations. 


m This may seem peculiar to those accustomed to thinking of a program as consist- 
ing of a series of executable statements, along with the appropriate declarations of 
variables. Consider though, that executable statements are contained within func- 
tions and that a function definition is itself a declaration. Conversely, because 
declarations can contain initializers, declarations can also be considered executable. 
o 


A name of file scope that is explicitly declared static is local to its transla- 
tion unit and can be used as a name for other objects, functions, and so on, in other 
translation unit. Such names are said to have internal linkage. A name of file 
scope that is explicitly declared inline is local to its translation unit. A name of 
file scope that is explicitly declared const and not explicitly declared extern is 
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local to its translation unit. So is the name of a class that has not been used in the 
declaration of an object, function, or class that is not local to its translation unit and 
has no static members (§9.4) and no noninline member functions (§9.3.2). Every 
declaration of a particular name of file scope that is not declared to have intemal 
linkage in one of these ways in a multifile program refers to the same object (§3.7), 
function (§8.2.5), or class (§9). Such names are said to be external or to have 
external linkage. In particular, since it is not possible to declare a class name 
Static, every use of a particular file scope class name that has been used in the 
declaration of an object or function with external linkage or has a static member or 
a noninline member function refers to the same class. 


m Note that two classes that in any way have been used to specify a form of extemal 
linkage may not have the same name. C+ relies on name equivalence (§9.1). O 


Typedef names (§7.1.3), enumerators (§7.2), and template names ($14) do not 
have external linkage. 

Static class members (§9.4) have external linkage. 

Noninline class member functions have external linkage. Inline class member 
functions must have exactly one definition in a program. 


@ This last constraint is almost impossible to enforce in an environment with 
genuinely independent compilation of the parts of a program, but easy to check 
where a compiler uses information stored between compilations. It is essential 
Where virtual functions are used. Had definitions of different versions of a member 
function in different parts of a program been allowed the definition of a class would 
have been incoherent and it would have been undefined which version of a virtual 
function should be called (§10.2). The only safe use of class member inline func- 
tions is to define each once and include it with its class declaration. O 


Local names (§3.2) explicitly declared extern have external linkage unless 
already declared static (§7.1.1). 

The types specified in all declarations of a particular extemal name must be 
identical except for the use of typedef names (§7.1.3) and unspecified array bounds 
(§8.2.4). There must be exactly one definition for each function, object, class and 
enumerator used in a program. If, however, a function is never called and its 
address is never taken, it need not be defined. Similarly, if the name of a class is 
used only in a way that does not require its definition to be known, it need not be 
defined. 


m If a name is just declared and never used, it need not be defined. For example, 


extern f(); 
main() { } 


Is a complete and correct program. O 


A function may be defined only in file or class scope. weer 
Linkage to non-C+ declarations can be achieved using a linkage-specification 
(§7.4). 


Section 3.4 Start and Termination 19 


3.4 Start and Termination 


A program must contain a function called main(). This function is the designated 
start of the program. This function is not predefined by the compiler, it cannot be 
overloaded, and its type is implementation dependent. It is recommended that the 
two examples below be allowed on any implementation and that any further argu- 
ments required be added after argv. The function main () may be defined as 


ant main() { (747... 47) } 
or 
int main(int argc, char* argv[]) { /* ... */ } 


In the latter form argc shall be the number of parameters passed to the program 
from an environment in which the program is run. If argc is nonzero these 
parameters shall be supplied as zero-terminated strings in argv[0] through 
argv [argc-1] and argv[0] shall be the name used to invoke the program or 
"". Tt is guaranteed that argv [argc] ==0. 

The function main() may not be called from within a program. The linkage 
(§3.3) of main() is implementation dependent. The address of main() cannot 
be taken and main() may not be declared inline or static. 


m This is to ensure full freedom of the implementer of the interface between a CH 
program and its environment. One could even imagine an implementation where 
main () was not implemented as a function. O 


Calling the function 
void exit (int); 


declared in <stdlib.h> terminates the program. The argument value is retuned 
to the program's environment as the value of the program. 

A retum statement in main () has the effect of calling exit () with the retum 
value as the argument. 

The initialization of nonlocal static objects (§3.5) in a translation unit is done 
before the first use of any function or object defined in that translation unit. Such 
initializations (§8.4, $9.4, §12.1, §12.6.1) may be done before the first statement of 
main () or deferred to any point in time before the first use of a function or object 
defined in that translation unit. The default initialization of all static objects to zero 
(§8.4) is performed before any dynamic (that is, run-time) initialization. No further 
order is imposed on the initialization of objects from different translation units. 
The initialization of local static objects is described in §8.4. 


m Note that it is not in general possible to complete dynamic initialization of every 
nonlocal static object before its use. 
Consider 
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//filel: 
extern y; 
int x = ytl; 


// file2: 
extern x; 
int y = xtl; 


Here, a mutual dependency exists that makes it impossible to define the values of x 
and y at the start of main (), that is after the dynamic initialization has taken place. 
Either the dynamic initialization for file1 takes place before the dynamic initial- 
ization of file2 and x==1 and y==2 or the order is reversed and we get x==2 
and y==1, Because the static initialization to 0 takes place before dynamic initial- 
ization there are no further possibilities for the values of x and y. 

For a given implementation it is possible to control the order of dynamic initial- 
ization, but it is usually wise to avoid dependencies on dynamic initialization order. 
Where such order is essential, placing the definitions of the global objects involved 
in a single translation unit is the only portable way of assuring a specific order. 

A useful technique for ensuring that a global object is initialized only once and 
before its first use is to maintain a count of the number of translation units using it. 
For example, consider writing a library that provides some statically allocated objects 
that must be initialized before the first use of the facilities of the libraries. 


// file nifty_library.h: 


VEL OOS 
extern X1 objl; 
ME waa 
extern Xn objn; 


If these objects require dynamic initialization, we have a problem: the dynamic 
initialization of the translation unit or translation units holding the definitions cannot 
(except by special system-dependent and extra-linguistic magic) be assumed to be 
performed before the dynamic initialization of all users. To solve this problem we 
add to nifty library.h 


class nifty counter { 
static count; 
Public: 


nifty_counter() 
{ 
if (count++ == 0) { 
// initialize objl ... objn 
} 
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~nifty counter () 
í 
if (--count == 0) { 
// clean up objl ... objn 
} 


He 
Static nifty counter nifty; 


Now every file that includes the library header also creates a nifty counter 
object and initializes it with the effect of increasing nifty counter: :count. 
The first time this happens the library objects will be initialized. Since the library 
header appears before any use of the library facilities this ensures proper initial- 
ization. Since destruction is done in reverse order of construction, this technique 
also ensures that cleanup is done after the last use of the library.. 

We believe this technique has been independently discovered many times. Jerry 
Schwarz pioneered its use in CH by using it for construction and destruction of 
cout, cin, and others, in the iostream library. These objects are constructed before 
the first I/O operation, and destroyed (with the effect of flushing their buffers) after 
the last. O 


Destructors (§12.4) for initialized static objects are called when returning from 
main() and when calling exit (). Destruction is done in reverse order of 
initialization. The function atexit () from <stdlib.h> can be used to specify 
that a function must be called at exit. If atexit() is to be called, objects initial- 
ized before an atexit () call may not be destroyed until after the function speci- 
fied in the atexit() call has been called. Where a CH implementation coexists 
with a C implementation, any actions specified by the C implementation to take 
place after the atexit() functions have been called take place after all 
destructors have been called. 

Calling the function 


void abort (); 


declared in <stdlib.h> terminates the program without executing destructors for 
static objects and without calling the functions passed to atexit (). 


m Typically, abort () has additional, system-dependent, effects. For example, 
abort () often saves information that allows a post-mortem on the program. O 


3.5 Storage Classes 
There are two declarable storage classes: automatic and static. 
Automatic objects are local to each invocation of a block. 


Static objects exist and retain their values throughout the execution of the 
entire program. 


eet 
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Local objects are initialized (§12.1) each time the control flow reaches their 
definition and destroyed (§12.4) on exit from their block ($6.7). 

A named local object may not be destroyed before the end of its block nor may 
a local named object of a class with a constructor or a destructor with side effects 
be eliminated even if it appears to be unused. 


m There are programming techniques relying exclusively on side effects of the 
initialization and cleanup of such objects. For example, 
Class Tracer { 
char* p; 
public: 
Tracer(char* s) 
{ p= s; cerr << s << " entered\n"; ) 
~Tracer() 
( cerr << “exit: from " << p-<< ‘\n'; } 
I: 


void f() 

{ 
Tracer ("f"); 
if eH 


o 


Similarly, a global object of a class with a constructor or a destructor with side 
effects may not be eliminated even if it appears to be unused. 


® Such objects are sometimes used for library initialization as described in §3.4. O 


Static objects are initialized and destroyed as described in §3.4 and §6.7. Some 
objects are not associated with names; see §5.3.3 and §12.2. All global objects 
have storage class static. Local objects and class members can be given static 
Storage class by explicit use of the static storage class specifier (§7.1.1). 


3.6 Types 


There are two kinds of types: fundamental types and derived types. 


3.6.1 Fundamental Types 


There are several fundamental types. The standard header <limits .h> specifies 
the largest and smallest values of each for an implementation. 


m The minimum values that will satisfy the ANSI C Standard are given in §3.2. O 


Objects declared as characters (char) are large enough to store any member of 
the implementation’s basic character set. If a character from this set is stored in a 
character variable, its value is equivalent to the integer code of that character. 
Characters may be explicitly declared unsigned or signed. Plain char, 
Signed char, and unsigned char are three distinct types. A char, a 


CIETE TO oT 
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signed char, and an unsigned char consume the same amount of space. 


m An implementation must specify whether the high-order bit of a char object that 
is neither explicitly signed nor unsigned is treated as a sign bit. Generally, the 
treatment chosen will take advantage of the instructions the target hardware executes 
most efficiently. Leaving this aspect of the language implementation-dependent is a 
common source of portability problems. Resolving these problems by simply defin- 
ing chars to be unsigned (or signed) would lead to incompatibilities with C, 
however, and programmers rightfully expect C compatibility in such basic matters. 
oO 


Up to three sizes of integer, declared short int, int, and long int, are 
available. Longer integers provide no less storage than shorter ones, but the imple- 
mentation may make either short integers or long integers, or both, equivalent to 
plain integers. Plain integers have the natural size suggested by the machine archi- 
tecture; the other sizes are provided to meet special needs. 


m This implies that the signed char, short, int, and long types may all be of 
the same size. A signed char will usually be smaller than a short, but it is not 
uncommon for an int to be the same size as either a short or a long. O 


For each of the types signed char, short, int, and long, there exists a 
corresponding unsigned type, which occupies the same amount of storage and 
has the same alignment requirements. An alignment requirement is an 
implementation-dependent restriction on the value of a pointer to an object of a 
given type (§5.4). 


m Typically implementations impose restrictions on where objects of given types 
may be allocated to ensure better use of memory access hardware. For example, it 
is often required that ints are allocated so that they do not straddle hardware word 
boundaries. 0 


Unsigned integers, declared unsigned, obey the laws of arithmetic modulo 2” 
where n is the number of bits in the representation. This implies that unsigned 
arithmetic does not overflow. 


m Typical integer type sizes and alignments: 


byte 
alignment 





o 


There are three floating types: float, double, and long double. The type 
double provides no less precision than float, and the type long double pro- 
vides no less precision than double. An implementation will define the 
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characteristics of the fundamental floating point types in the standard header 
<float.h>. 


m The minimum values that will satisfy the ANSI C Standard are given in §3.2.2. 
Typical floating point type sizes and alignments: 


size 
(in bytes) 








byte 
alignment 













float 4 4 
double 8 4or8 
long double 12 or 16 | 40r8 or 16 


Oo 


Types char, int of all sizes, and enumerations (§7.2) are collectively called 
integral types. Integral and floating types are collectively called arithmetic types. 

The void type specifies an empty set of values. It is used as the return type 
for functions that do not retum a value. No object of type void may be declared. 
Any expression may be explicitly converted to type void (§5.4); the resulting 
expression may be used only as an expression statement (§6.2), as the left operand 
of a comma expression (§5.18), or as a second or third operand of ?: (§5.16). 


3.6.2 Derived Types 


There is a conceptually infinite number of derived types constructed from the fun- 
damental types in the following ways: 


arrays of objects of a given type, §8.2.4; 


functions, which take arguments of given types and retum objects of a given 
type, §8.2.5; 


pointers to objects or functions of a given type, §8.2.1; 

references to objects or functions of a given type, §8.2.2; 

constants, which are values of a given type, §7.1.6; 

classes containing a sequence of objects of various types (§9), a set of func- 
tions for manipulating these objects (§9.3), and a set of restrictions on the 
access to these objects and functions, §11; 


structures, which are classes without default access restrictions, §11; 


unions, which are structures capable of containing objects of different types 
at different times, §9.5; 
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pointers to class members, which identify members of a given type within 
objects of a given class, §8.2.3. 


In general, these methods of constructing objects can be applied recursively; 
restrictions are mentioned in §8.2.1, §8.2.4, §8.2.5, and §8.2.2. 


m We refer to classes (including structures and unions) as user-defined types and 
other types as built-in types. O 


A pointer to objects of a type T is referred to as a “‘pointer to T.” For exam- 
ple, a pointer to an object of type int is referred to as ‘‘pointer to int’’ and a 
pointer to an object of class X is called a *‘pointer to X.” 

Objects of type void* (pointer to void), const void*, and volatile 
void* can be used to point to objects of unknown type. A void* must have 
enough bits to hold any object pointer. 


m A pointer to a nonstatic member is not considered an object pointer. Thus, the 
requirement that type void* be large enough to hold any object pointer (§3.6.2) 
does not mean that void* must be large enough to hold a pointer to function or a 
pointer to member. 

A pointer to a static member, however, is treated as an ordinary pointer. Thus, 
given 


class X { 
public: 
static int Xcount; 
he 
applying the & operator to X::Xcount yields type int’, not type int X::*. 
Therefore the following is correct: 


int* p = &X::Xcount; 
o 


Except for pointers to static members, text referring to ‘‘pointers’’ does not 
apply to pointers to members. 


3.6.3 Type Names 


Fundamental and derived types can be given names by the typedef mechanism 
(§7.1.3), and families of types and functions can be specified and named by the 
template mechanism (§14). 


3.7 Lvalues 


An object is a region of storage; an /value is an expression referring to an object or 
function. An obvious example of an lvalue expression is the name of an object. 
Some operators yield Ivalues. For example, if E is an expression of pointer type, 
then *E is an lvalue expression referring to the object to which E points. The 
name ‘‘Ilvalue’? comes from the assignment expression E1 = E2 in which the left 
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operand E1 must be an Ivalue expression. The discussion of each operator in §5 
indicates whether it expects Ivalue operands and whether it yields an Ivalue. An 
lvalue is modifiable if it is not a function name, an array name, or const. 














Commentary 





3.lc Name Spaces 


CH puts type names in the same name space as other names, unlike C, which pro- 
vides a separate name space for structure tags. For example, 


struct stat {f 
PE LS RO 
he 


extern struct stat stat(int, struct stat *); 


was originally not legal CH, although even early implementations accepted it for 
compatibility. 

On the other hand, providing a single name space gives important notational 
conveniences to CH programmers. Consider a class complex 


class complex { 
HE ets 
}; 


for which an object can be declared as follows: 
complex cl; 


Without the single name space, every declaration of a complex object or argu- 
ment type would have to include the class keyword. 


class complex cl; 


All casts to class types would be similarly burdened. 

Requiring that such prefixing always appear would compromise the effort to 
make use of user-defined types, such as complex, as similar as possible to use of 
built-in types, such as int. 

Experience has shown, however, that simply imposing a single name space 
causes too much confusion and too much inconvenience for too many users. Con- 
sequently, a refined version of the C/CH compatibility compromise is now incor- 
porated into CH; see §9.1. 

This name space compromise enables all accepted uses of multiple name spaces 


OTD 
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in C while preserving the notational convenience of CH when compatibility with C 
isn’t an issue. In particular, every formerly legal C+ program remains legal. 

A typedef can declare a name to refer to the same type more than once. For 
example, 


typedef struct s { /* ... */ } 3s; 
typedef s s; 


A name s can be declared as a type (struct, class, union, enum) and as a non- 
type (function, object, value, and so on) in a single scope. In this example, after 
both declarations of s have been seen, the name s refers to the nontype and 
struct s can be used to refer to the type. The order of declaration does not 
matter. For example, 


struct stat { /* ..+ */ J? 


stat a; // same as ‘‘struct stat a;’’ 
void stat(stat* p); 

struct stat b; // struct keyword is needed 
stat (0); // function call 


int f(int); 


f(1); 
union £ C/E ses */ Je 
union f g; // union keyword is needed 


A name cannot simultaneously refer to two types. 


class t T A Tan Sf ie 
typedef int c; // error 


If a nontype name s hides a type name s, struct s (or class s, union 
s, or enum s, as the case may be) can be used to refer to the type name. For 
example, 


struct s { /* a */7 }; 
void f(int s) { struct s a; stt; } 


If a type name hides a nontype name the usual scoping rules apply (§3.2). 


int s = 0; 

void f() 

struct s { /* ... */ }: // global int s is hidden 
eee 3; // refers to global int s 


// struct s is out of scope 
// int s is visible 
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3.2c Numerical Limits 


This section defines the minimum numerical limits that a CH implementation con- 
sistent with the ANSI C Standard will provide in the header files <limits.h> 
and <float.h>. 


3.2.1c Integral Limits 


An implementation that provides functionality consistent with ANSI C will define 
the sizes of integral types in the <limits.h> header file. The values listed 
below are the minimum magnitude values that will satisfy ANSI; values of larger 
magnitude may be given. 


CHAR_BIT 8 maximum bits in a byte 
SCHAR_MIN -127 minimum value of signed char 
SCHAR_MAX +127 maximum value of signed char 
UCHAR_MAX 255 maximum value of unsigned char 
CHAR_MIN 0 

or SCHAR MIN minimum value of char 
CHAR_MAX UCHAR_MAX 

or SCHAR MAX maximum value of char 
MB LEN MAX 1 maximum bytes in a multibyte character 
SHRT_MIN -32767 minimum value of short 
SHRT_MAX +32767 maximum value of short 
USHRT_MAX 65535 maximum value of unsigned short 
INT MIN -32767 minimum value of int 
INT_MAX +32767 maximum value of int 
UINT_MAX 65535 maximum value of unsigned int 
LONG MIN -2147483647 minimum value of long 
LONG_MAX +2147483647 maximum value of long 
ULONG MAX 4294967295 maximum value of unsigned long 


The value of CHAR MIN will be SCHAR_MIN if the value of a char is sign- 


extended when used in an expression, and 0 otherwise. The value of CHAR_MAX 
will be SCHAR MAX if a char is sign-extended in an expression, and 
UCHAR_MAX otherwise. 


3.2.2c Floating Limits 


An implementation that provides functionality consistent with ANSI C will define 
the characteristics of floating types in the <float.h> header file. Where a value 
is given below, it is the minimum magnitude value that will satisfy ANSI; an 
implementation may provide values of larger magnitude. 


FLT_RADIX 2 radix of exponent representation 


oe oo oe ee 
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FLT_MANT_DIG 
FLT_DIG 
FLT_MIN_EXP 


FLT MIN 10 EXP 


FLT_MAX_EXP 
FLT MAX 10 EXP 


FLT MAX 
FLT_EPSILON 


FLT_MIN 
DBL_MANT DIG 


DBL_DIG 
DBL_MIN_EXP 


DBL_MIN_10 EXP 


DBL MAX EXP 
DBL_MAX_10_EXP 


DBL_MAX 
DBL_EPSILON 


DBL_MIN 


LDBL_MANT DIG 
LDBL_DIG 
LDBL_MIN_EXP 


LDBL_MIN_10_EXP 


-= 


+37 


1E+37 
1E-5 


1E-37 


10 


=37 


+37 


1E+37 
1E-9 


1E-37 


10 
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number of base FLT_RADIX digits in mantissa 
decimal digits of precision 

minimum negative integer such that 
FLT_RADIX raised to the nth minus | is a 
normalized floating point number 

minimum negative integer n such that 10 
raised to the nth is within the range of 
normalized floating point numbers 

maximum integer n such that FLT_RADIX 
raised to the nth minus 1 is representable 
maximum integer n such that 10 raised to the 
nth is representable 

maximum representable floating point number 
minimum positive number x such that 

1.0 + x does not equal 1.0 

minimum normalized positive floating point 
number 


number of base FLT_RADIX digits in mantissa 
decimal digits of precision 

minimum negative integer n such that 
FLT_RADIX raised to the nth minus | is a 
normalized floating point number 

minimum negative integer n such that 10 
raised to the nth is within the range of 
normalized floating point numbers 

maximum integer n such that FLT_RADIX 
raised to the mth minus | is representable 
maximum integer n such that 10 raised to the 
nth is representable 

maximum representable floating point number 
minimum positive number x such that 

1.0 + x does not equal 1.0 

minimum normalized positive floating point 
number 


number of base FLT_RADIX digits in mantissa 
decimal digits of precision 

minimum negative integer n such that 
FLT_RADIX raised to the nth minus | is a 
normalized floating point number 

minimum negative integer n such that 10 
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raised to the nth is within the range of 
normalized floating point numbers 


LDBL_MAX_EXP maximum integer n such that FLT_RADIX 
raised to the nth minus 1 is representable 
LDBL_MAX_10 EXP +37 maximum integer n such that 10 raised to the 
z nth is representable 
LDBL_MAX 1E+37 maximum representable floating point number 
LDBL_EPSILON 1E-9 minimum positive number x such that 
1.0 + x does not equal 1.0 
LDBL_MIN 1E-37 minimum normalized positive floating point 
number 


Many implementations will also provide the definitions required to satisfy the 
IEEE Standard for Binary Floating-Point Arithmetic. 














Standard Conversions 


This chapter presents standard type conversions, including integral promotions, 
integral conversions, floating point conversions, conversions between floating 
and integral types, and arithmetic conversions, as well as pointer, reference, and 
pointer to member conversions. 


4 Standard Conversions 


Some operators may, depending on their operands, cause conversion of the value of 
an operand from one type to another. This section summarizes the conversions 
demanded by most ordinary operators and explains the result to be expected from 
such conversions; it will be supplemented as required by the discussion of each 
operator. These conversions are also used in initialization (§8.4, §8.4.3, §12.8, 
§12.1). §12.3 and §13.2 describe user-defined conversions and their interaction 
with standard conversions. The result of a conversion is an lvalue only if the result 
is a reference (§8.2.2). 


m Conversions for the fundamental types (§3.6.1) are defined in C+ as they are in 
ANSI C. The conversion rules for arithmetic types and the way implementation 
dependencies affect them are summarized in the commentary section at the end of 
this chapter. O 


4.1 Integral Promotions 


A char, a short int, enumerator, object of enumeration type (§7.2), or an int 
bit-field (§9.6) (in both their signed and unsigned varieties) may be used wherever 
an integer may be used. If an int can represent all the values of the original type, 
the value is converted to int; otherwise it is converted to unsigned int. This 
process is called integral promotion. 
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m CH follows ANSI C in defining integral promotions as ‘‘value-preserving.'’ That 
is, a Char, a short, or an int bit field, or their signed or unsigned varieties, will 
be widened to int if int can represent all the values of the original type or to 
unsigned int otherwise. 

In this respect, however, ANSI C introduces an incompatibility with Classic C, 
from which most older CH implementations are derived. Many Classic C compilers 
use “‘unsigned-preserving"’ integral promotions. When an unsigned char or an 
unsigned short is widened, it becomes an unsigned int. 

Although the two schemes will usually yield the same result, value-preserving 
Promotion will give different results from an unsigned-preserving promotion when 
the following two conditions are both true (yielding a ‘*questionably signed’’ result): 


An integral constant with a value greater than the largest signed int value 

on the target machine appears in an expression, or an expression involving 

an unsigned char, an unsigned short, or a bit field with any 

unsigned type except unsigned long and size smaller than int pro- 

duces a result in which the high-order bit is set. 

The result of that expression 

— is an operand of a predefined operator /, $, /=, $=, <, <=, >, or >=, Or 

— ona machine for which >> is a signed right shift, is the left operand of 
the predefined >> or >>= operator, or 

— is an operand of a user-defined operator (§13) for which the result 
depends on the sign of its operand. 


The following code, for example, yields a questionably signed result if 
Sizeof (short)<sizeof (int): 


void f(int i,unsigned short us) 


{ 
ada 
int k = (i + us) < 42; 
I foot 

} 


Suppose £() is passed the values —1 for i and 2 for us. Under the ANSI C rule 
us will be promoted to int, yielding the expression (-1 + 2) < 42 and k will 
be assigned 1. Under the Classic C rule, us will be promoted to unsigned int 
and i's value must also be promoted to unsigned int before the addition. The 
result of this promotion of —1 is some large value, which when added to 2 is not 
less than 42, so k is assigned 0. 

The appropriate use of casts will ensure consistent evaluation using both Classic 
C and ANSI C rules. For example, 


k = (i + (unsigned int)us) < 42; // force ANSI C style 
k = (i + (int)us) < 42; // force Classic C style 


It will take some time before all CH implementations follow the ANSI C rule by 
default. O 


Section 4.2 Integral Conversions 33 


4,2 Integral Conversions 


When an integer is converted to an unsigned type, the value is the least unsigned 
integer congruent to the signed integer (modulo 2” where n is the number of bits 
used to represent the unsigned type). In a two's complement representation, this 
conversion is conceptual and there is no change in the bit pattern. 

When an integer is converted to a signed type, the value is unchanged if it can 
be represented in the new type; otherwise the value is implementation dependent. 


@ An unsigned type must be of the same size as its corresponding plain type, which 
must be of the same size as the corresponding explicitly signed type (§3.6.1). It fol- 
lows that an unsigned type can hold a larger value than its corresponding signed 
type. Thus it is not safe to conven from an unsigned type to its corresponding 
signed type. It is safe to convert from an unsigned type to a larger signed type. 
Thus, for example, converting from unsigned short to int on an implementa- 
tion for which an int is larger than a short will be safe. Note, however, that an 
implementation may define the types char, short, int, and long all to be of the 
same size. On such an implementation no conversion from an unsigned integral type 
to a signed integral type is safe, not even unsigned char to long. 

The result of demoting an integer to a shorter signed integer is implementation 
dependent. Typically the low-order bits from the longer integer will be copied to the 
shorter signed integer, a negative value may result. 

Similarly, the result of converting an unsigned integer to a signed integer of 
equal length is implementation dependent. If the bits from the unsigned integer are 
copied to the signed integer, as will usually be done, a negative value may result. O 


4.3 Float and Double 


Single-precision floating point arithmetic may be used for float expressions. 
When a less precise floating value is converted to an equally or more precise float- 
ing type, the value is unchanged. When a more precise floating value is converted 
to a less precise floating type and the value is within representable range, the result 
may be either the next higher or the next lower representable value. If the result is 
out of range, the behavior is undefined. 


m The set of values that can be represented as a float is a subset of the set of 
values that can be represented as a double; the set of values that can be 
represented as a double is a subset of the set of values that can be represented as a 
long double (see §3.2.2). Thus it is always safe to convert from float to 
double or from double to long double. O 


4.4 Floating and Integral 


Conversion of a floating value to an integral type truncates; that is, the fractional 
part is discarded. Such conversions are machine dependent; for example, the direc- 
tion of truncation of negative numbers varies from machine to machine. The result 
is undefined if the value cannot be represented in the integral type. 
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Conversions of integral values to floating type are as mathematically correct as 
the hardware allows. Loss of precision occurs if an integral value cannot be 
represented exactly as a value of the floating type. 


m C+ defines integral and floating point types consistently with ANSI C, in terms of 
minimum magnitude values (see §3.2.1 and §3.2.2). Other than these minimum 
magnitudes, there is no defined relationship between the floating point and integral 
types. In particular, there is no upper limit on the maximum value an implementa- 
tion can support in any of the integral types. It follows, contrary to popular miscon- 
ception, that the safety of any conversion from an integral type to a floating type is 
implementation dependent. 

The result of the conversion of a value of an integral type to a floating type 
when the value is in the range of values that can be represented but cannot be 
represented exactly will be implementation dependent. It can be either the nearest 
higher or nearest lower value. In many implementations the result will depend on 
the setting of a rounding mode provided in a library, O 


4.5 Arithmetic Conversions 


Many operators cause conversions and yield result types in a similar way. This 
pattern will be called the ‘‘usual arithmetic conversions.”’ 


If either operand is of type long double, the other is converted to long 
double. 


Otherwise, if either operand is double, the other is converted to double. 
Otherwise, if either operand is float, the other is converted to float. 
Otherwise, the integral promotions (§4.1) are performed on both operands. 


Then, if either operand is unsigned long the other is converted to 
unsigned long. 


Otherwise, if one operand is a long int and the other unsigned int, 
then if a long int can represent all the values of an unsigned int, the 
unsigned int is converted to a long int; otherwise both operands are 
converted to unsigned long int. 


Otherwise, if either operand is long, the other is converted to long. 


Otherwise, if either operand is unsigned, the other is converted to 
unsigned. 





Otherwise, both operands are int. 
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@ The rules for arithmetic conversion (§4.5) specify an order of conversions to be 
applied to bring the values of operands of differing types to a common type before 
their operator is applied; they do not, however, imply a mechanism for disambiguat- 
ing calls to overloaded functions (§13, §13.2). 


Consider 
int a = 8; 
a *= ,5; 


According to the arithmetic conversion rules, the generated code for the multiplica- 
tion will first promote the value of a to double, then do a floating point multipli- 
cation, convert the resulting value to int, and finally assign the result to the a. 
Some implementations will issue a warning about the assignment of a double to an 
int. 

Now consider 


float b = 8.0; 
b *= 1/2; 


Because both operands of the division operator are of type int, an integer division 
is done and the result is the int value 0. This value is converted to float and 
then the multiplication is done, yielding 0.0. Even though the result of the division 
will be used in an expression with a float operand, it is an integer operation with 
integer operands. Any of the following would involve floating point division: 


float c = 8.0; 

c *= 1.0/2; // c gets 4.0 
c tæ 1/2.0; // c gets 2.0 
c *= 1.0/2.0; // c gets 1.0 


Like ANSI C, C+ generates code for operations involving only float (and not 
double or long double) operands without widening to double. Classic C, 
however, promotes float operands in expressions to double before evaluation. 
Code generated for computations without widening float operands may produce a 
difference in the least significant bits for each floating point operation compared 
with code that promotes float operands. Declaring objects to be of type double 
or using casts will yield evaluation of floating point expressions as done by Classic 
os 

Some conversions lose information and others cause the bit pattem representing 
the value to be interpreted differently; see §4.1. O 


4.6 Pointer Conversions 


The following conversions may be performed wherever pointers (§8.2.1) are 
assigned, initialized, compared, or otherwise used: 


A constant expression (§5.19) that evaluates to zero is converted to a 
pointer, commonly called the null pointer. It is guaranteed that this value 
will produce a pointer distinguishable from a pointer to any object. 
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E Note that the null pointer need not be represented by the same bit pattern as 
the integer 0. O 


A pointer to any non-const and non-volatile object type may be con- 
verted to a voids. 


A pointer to function may be converted to a void* provided a void* has 
sufficient bits to hold it. 


A pointer to a class may be converted to a pointer to an accessible base 
class of that class (§10) provided the conversion is unambiguous (§10.1); a 
base class is accessible if its public members are accessible (§11.1). The 
result of the conversion is a pointer to the base class sub-object of the 
derived class object. The null pointer (0) is converted into itself. 


An expression with type ‘‘array of T” may be converted to a pointer to the 
initial element of the array. 


An expression with type ‘‘function returning T"’ is converted to ‘‘pointer to 
function returning T’’ except when used as the operand of the address-of 
operator & or the function call operator (). 


m The standard conversion of a derived class pointer to a pointer to one of its bases 
can be done only by a function that can access that class. That is, if the base is a 
public base then every function can do the conversion. If the base is private, the 
function needs to be a friend, member, or a member of a class that has the base as 
its immediate class. In those cases the conversion is performed implicitly. O 


m C+ differs from ANSI C in the treatment of void*. ANSI C allows an implicit 
conversion from a pointer to void to a pointer to another object type (but not to a 
pointer to function type — see §5.4); in CH a void* cannot be assigned to an 
object of any type other than void* without an explicit cast. Thus, the following is 
legal ANSI C, but is not accepted in C+: 


void f(char* cptr, void* vptr) 
{ 


cptr = vptr; // error: cannot assign void* to char* 


) 


By accepting this, ANSI C opens a hole in the type system that was not present 
in Classic C. We surmise that the hole was opened to save programmers tedious 
casting of the result of malloc (). For example, 
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int* pl = (int*)malloc(sizeof(int)*sz); // tedious 


int* p2 = malloc(sizeof(int)*sz); // error, but 
// allowed in ANSI C 
In C+, operator new is a safer and more convenient alternative. 


int* p3 = new int[sz]; 
Consequently, C+ need not open that hole in the type system. O 
@ The restriction against implicit conversions that remove ‘‘constness’’ is an exam- 


ple of the more general rule that constraints may not simply disappear without the 
use of an explicit cast. For example, 


const char v[] = "Nicholas"; 
void* p = v; // error: v points to const 
void* q = (char*)v; // ok (on your head be it!) 


It is implementation dependent whether an attempt to write elements of v through q 
will succeed; see §2.5.4.0 


m A pointer to any non-const and non-volatile type can be converted, by a 
standard conversion, to a pointer to void, provided void* is big enough to hold 
the result of the conversion (§4.6). 

For example, 


char* cptr; 
int* iptr; 
void* vptr; 


void f(int i) 
{ 
vptr = i ? iptr < vptr; 
vptr = i ? vptr : cptr; 
} 


Here, each of the pointers iptr and cptr, when used in an expression with the 
pointer to void, vptr, will be implicitly converted to void*. Use of pointers to 
different types in the same expression, as in 


vptr = cptr ? iptr : cptr; // error: type mismatch 


is not legal — there is no standard conversion from a pointer to one type to a pointer 
to another type (other than void*). If a pointer to one type absolutely must be con- 
verted to a pointer to another type (other than void*), an explicit conversion can be 
used (§5.4). O 


m The rule that says that the null pointer is converted into itself is relevant for 
conversions of the null pointer between different derived types in a multiple inheri- 
tance lattice (§10.1). O 
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m Except for pointers to static members, pointers to members are not implemented or 
handled as ordinary pointers. The discussions of conversions and uses of pointers do 
not apply to pointers to members; conversions of nonstatic pointers to members are 
discussed in §4.8. O 


4.7 Reference Conversions 


The following conversion may be performed wherever references (§8.2.2) are ini- 
tialized (including argument passing (§5.2.2) and function value return (§6.6.3)): 


A reference to a class may be converted to a reference to an accessible base 
class (§10, §11.1) of that class (§8.4.3) provided this conversion can be done 
unambiguously (§10.1.1). The result of the conversion is a reference to the 
base class sub-object of the derived class object. 


m Reference conversions behave much like pointer conversions. Note, however, that 
reference conversions occur only where references are initialized. 
Given the declarations 


class B { 
PRVE 

J}; 

class D : public B [ 
E er 

Jz 

void f(B&); 

D d; 

Dé dr=d; 


the following call is legal: 
f (dr); // equivalent to f((B&)d); 


o 


m Note that since copying is defined in terms of reference arguments, the implicit 
conversions of a reference to a derived class to references to its base classes implies 
implicit conversion of an object of a derived class to objects of its base classes; see 
§5.17, §12.8. D 


4.8 Pointers to Members 


The following conversion may be performed wherever pointers to members (§8.2.3) 
are initialized, assigned, compared, or otherwise used: 


A constant expression (§5.19) that evaluates to zero is converted to a 
pointer to membet. It is guaranteed that this value will produce a pointer to 
member distinguishable from any other pointer to member. 


3 


zir 
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A pointer to a member of a class may be converted to a pointer to member 
of a class derived from that class provided the (inverse) conversion from the 
derived class to the base class pointer is accessible (§11.1) and provided this 
conversion can be done unambiguously (§10.1.1). - 


The rule for conversion of pointers to members (from pointer to member of 
base to pointer to member of derived) appears inverted compared to the rule for 
pointers to objects (from pointer to derived to pointer to base) (§4.6, §10). This 
inversion is necessary to ensure type safety. 


m This may seem backwards at first. Consider 


class B { 
public: 

int bi; 
Me 


class D : public B { 


public: 

int di; 
le 
B bs 
B* bp = &b; 
int B::*bpm; 
Dd; 
D* dp = &d; 


int D::*dpm; 


Now suppose bpm is implicitly converted to pointer to member of D, as in the fol- 
lowing: 

bpm = &B::bi; 

d.*bpm = 1; // OK - sets d.bi 

dp->*bpm = 2; // OK - sets d.bi 


Because a D object always contains an object of its base class, B, converting bpm 
(which points to a member of a B object) to a pointer to member of D makes it point 
to D's bi. 
On the other hand, an implicit conversion of dpm to pointer to member of D’s 

base class cannot be allowed. The following is illegal: 

dpm = &D::d1; 

b.*dpm = 3; // error: b has no member di 

bp->*dpm = 4; // error: b has no member di 


An object of class B has no member di. Thus implicit conversion from a pointer to 
a derived class to a pointer to member of its base class cannot be allowed. 

There are no other standard conversions involving pointers to members, not even 
between a pointer to a member and void* or between a pointer to member and an 
integer. O 


Note that a pointer to member is not a pointer to object or a pointer to function 
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and the rules for conversions of such pointers do not apply to pointers to members. 
In particular, a pointer to member cannot be converted to a void*. 


m Pointers to static members are ordinary pointers (§3.6.2). O 





Commentary 





4.lc Arithmetic Conversions 


The original idea behind the variety of integral and floating point types in C was to 
have computation done at the natural precision of a machine and also to provide 
ways to store values of lesser precision compactly. For example, all integer com- 
putation was done in ints and small integers could be stored in shorts and 
chars. 

Some conversions lose information about the value converted and some cause 
the bit pattern representing the value to be interpreted differently. For example, 
converting a floating point value to an integer loses precision; the floating point 
value 4.261745 converted to an int is 4. Converting the value -1 stored as an 
int to an unsigned type yields a large positive value. 

The C+ rules for arithmetic conversions are summarized below. Arrows show 
conversions that are guaranteed safe. A conversion is said to be safe if all values 
of the operand type can be represented as values of target type without loss of pre- 
cision or change of numerical value. 

Conversions for the types char and w_char are not shown because they are 
not independent types, but synonyms for other types; char is a synonym for either 
signed char or unsigned char and w_char is a synonym for some integer 
type, usually short or unsigned short. 


— 
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signed char tant S| oe char 
char 
short cage en w char 
short = 





int float 
int | 
long double atic 
| long 


long double 
| 


One might expect many more conversions to be safe. For example, it is hard to 
imagine an implementation where an unsigned char cannot be converted to a 
long, but since only 


sizeof(char) <= sizeof (long) 
is guaranteed, an implementation might (perversely) define the types such that 
sizeof (char) == sizeof (long) 


This would make it impossible to convert the highest unsigned char value to a 
long with the same integer value. 

An implementation, however, must not only be correct; it must also be useful. 
A typical implementation chooses the sizes of its basic types to provide a variety of 
object sizes, thus making many more conversions safe. To illustrate this we pro- 
vide examples of safe conversions for a couple of plausible implementations. 

A machine, such as a VAX, where 
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1 < sizeof(short) < sizeof(int) == sizeof (long) 
sizeof(int) == sizeof (float) 


Sizeof(float) < sizeof(double) == sizeof(long double) 


gives these safe coercions: 







h 
signed char ai 






unsigned char 










w_char 
unsigned short 










unsigned int 
unsigned long 







double 
long double 





Note that different implementations for the same hardware may make different 
choices for sizes. 

Some machines, such as Crays, designed for very high performance, lack the 
hardware to extract part of a word or store into a part of a word efficiently. Thus 


sizeof(short) == sizeof(int) == sizeof (long) 


becomes a reasonable implementation choice. Speed is bought at the expense of 
space. This gives these safe conversions: 
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signed char chax 


unsigned char 





w_char 

unsigned short 
unsigned 

unsigned long 


long double 


Note that a conversion from an integer type to a floating type depends on the 
range of numbers that can be represented exactly in the floating point type (the size 
of the mantissa) and not just the size of the floating point type. 

The only truly safe advice is: be careful. Machine architectures differ more 
than we like to imagine. 




















Expressions 


This chapter discusses CH expressions, the primary building blocks for computa- 
tion. CH provides the usual arithmetic operators (+, -, *, and so on), bit mani- 
pulation operators (&, |, ^, and so on), operators for pointer manipulation (*, &, 
[], ->), storage management (new and delete), conditional evaluation (?:, 
| 1, &&), and the pointer to member operators (. * and ->*). 


This chapter also describes explicit type conversions (‘‘casting”’). 


5 Expressions 


This section defines the syntax, order of evaluation, and meaning of expressions. 
An expression is a sequence of operators and operands that specifies a computation. 
An expression may result in a value and may cause side effects. 

Operators can be overloaded, that is, given meaning when applied to expres- 
sions of class type (§9). Uses of overloaded operators are transformed into func- 
tion calls as described in §13.4. Overloaded operators obey the rules for syntax 
specified in this section, but the requirements of operand type, Ivalue, and evalua- 
tion order are replaced by the rules for function call. Relations between operators, 
such as ++a meaning a+=1, are not guaranteed for overloaded operators (§13.4). 

This section defines the operators when applied to types for which they have 
not been overloaded. Operator overloading cannot modify the rules for operators 
applied to types for which they are defined by the language itself. 

m We repeat: the rules in this chapter do not cover expressions involving overloaded 
operators or user-defined conversion operations. See §13 for an explanation of those 
mechanisms. 

Note that C} is extensible in the sense that meanings of operators can be 
defined for user-defined types (that is, classes §9) but not mutable because the opera- 
tions described in this chapter cannot be redefined for the types for which they are 
defined here. The exception to this rule is assignment of class objects, the address- 
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of operator applied to class objects, and the comma operator when applied to a class 
object; these can be redefined. O 


The order of evaluation of subexpressions is determined by the precedence and 
grouping of the operators. The usual mathematical rules for associativity and com- 
mutativity of operators may be applied only where the operators really are associa- 
tive and commutative. Except where noted, the order of evaluation of operands of 
individual operators is undefined. In particular, if a value is modified twice in an 
expression, the result of the expression is undefined except where an ordering is 
guaranteed by the operators involved. For example, 


i = v[it+); // the value of ‘i’ is undefined 
i=7,itt,itt; // ‘it becomes 9 


m Compilers can detect and wam against the use of expressions with undefined order 
of evaluation. O 


m CH differs from Classic C in that a floating point operation may be performed in 
single precision provided both its arguments are floats (after standard conversions 
have been performed; §4). In this, CH agrees with ANSI C. Classic C required all 
floating point computation to be performed in double precision. O 


The handling of overflow and divide check in expression evaluation is imple- 
mentation dependent. Most existing implementations of Œ ignore integer over- 
flows. Treatment of division by zero and all floating point exceptions vary among 
machines, and is usually adjustable by a library function. 


@ If an exception handling scheme, such as the one described in §14, is adopted, one 
would map such events into standard exceptions so that they could be handled by 
user-provided code in a standard manner. O 


Except where noted, operands of types const T, volatile T, T&, const 
T&, and volatile T& can be used as if they were of the plain type T. Similarly, 
except where noted, operands of type T*const and T*volatile can be used as 
if they were of the plain type T*. Similarly, a plain T can be used where a vola- 
tile T or a const T is required. These rules apply in combination so that, 
except where noted, a const T*volatile can be used where a T* is required. 
Such uses do not count as standard conversions when considering overloading reso- 
lution (§13.2). 

If an expression has the type ‘‘reference to T” (§8.2.2, §8.4.3), the value of the 
expression is the object of type “*T’’ denoted by the reference. The expression is 
an Ivalue. A reference can be thought of as a name of an object. 

m Despite appearances, no operator operates on a reference. For example, 
int ivar = 0; 
inté int ref = ivar; 


int_reftt; 


Here int _ref++ does not increment the reference int_ref; rather, ++ is applied 
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to the int referred to by int_ref, in this case, ivar. O 


User-defined conversions of class objects to and from fundamental types, 
pointers, and so on, can be defined (§12.3). If unambiguous (§13.2), such conver- 
sions may be applied by the compiler wherever a class object appears as an 
operand of an operator, as an initializer (§8.4), as the controlling expression in a 
selection (§6.4) or iteration (§6.5) statement, as a function return value (§6.6.3), or 
as a function argument (§5.2.2). 


5.1 Primary Expressions 


Primary expressions are literals, names, and names qualified by the scope resolution 
operator : :. 


primary-expression: 
literal 
this 
:: identifier 
:: operator-function-name 
:: qualified-name 
( expression ) 
name 


A literal is a primary expression. Its type depends on its form (§2.5). 

In the body of a nonstatic member function (§9.3), the keyword this names a 
pointer to the object for which the function was invoked. The keyword this can- 
not be used outside a class member function body. 

The operator :: followed by an identifier, a qualified-name, or an operator- 
function-name is a primary expression. Its type is specified by the declaration of 
the identifier, name, or operator-function-name, The result is the identifier, name, 
or operator-function-name, The result is an lvalue if the identifier is. The identif- 
ier or operator-function-name must be of file scope. Use of :: allows a type, an 
object, a function, or an enumerator to be referred to even if its identifier has been 
hidden (§3.2). 


m Examples of use of the scope resolution operator, : <, can be found in $3.2. O 


A parenthesized expression is a primary expression whose type and value are 
identical to those of the unadorned expression. The presence of parentheses does 
not affect whether the expression is an lvalue. 

A name is a restricted form of a primary-expression that can appear after . and 
-> (§5.2.4): 
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name: 
identifier 
operator-function-name 
conversion-function-name 
~ class-name 
qualified-name 


An identifier is a name provided it has been suitably declared (§7). For 
operator-function-names, see §13.4. For conversion-function-names, see §12.3.2. 
A class-name prefixed by ~ denotes a destructor; see §12.4. 


qualified-name: 
qualified-class-name :: name 


A qualified-class-name (§9.1) followed by :: and the name of a member of 
that class (§9.2), or a member of a base of that class (§10), is a qualified-name; its 
type is the type of the member. The result is the member. The result is an Ivalue 
if the member is. The class-name may be hidden by a nontype name, in which 
case the class-name is still found and used. Where class-name :: class-name or 
class-name :: ~ class-name is used, the two class-names must refer to the same 
class; this notation names constructors (§12.1) and destructors (§12.4), respectively. 
Multiply qualified names, such as Nl::N2::N3::n, can be used to refer to 
nested types (§9.7). 


m For N1::N2::N3::n to be meaningful, N1 must be a class in which a class N2 
is declared, and a class N3 with a member n must be declared within N2. O 


5.2 Postfix Expressions 
Postfix expressions group left-to-right. 


postfix-expression: 
primary-expression 
postfix-expression | expression ) 
postfix-expression ( expression-list,,, ) 
simple-type-name ( expression-list,,, ) 
postfix-expression . name 
postfix-expression -> name 
postfix-expression ++ 
postfix-expression —— 


expression-list: 
assignment-expression 
expression-list , assignment-expression 
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5.2.1 Subscripting 


A postfix expression followed by an expression in square brackets is a postfix 
expression. The intuitive meaning is that of a subscript. One of the expressions 
must have the type ‘‘pointer to T” and the other must be of integral type. The 
type of the result is ‘*T.'" The expression E1(E2] is identical (by definition) to 
* ((E1)+(E2)). See §5.3 and §5.7 for details of * and + and §8.2.4 for details 
of arrays. 


m For example, given 
int i, 4(10); 


the array can be indexed by the integer like this afi]. The value of i must be 
between 0 and 9 for the result to be well-defined (§5.7). By definition, the expres- 
sion afi] means * (ati); since addition is commutative (§5.7 discusses addition 
of pointers), this is equivalent to *(ita). It follows therefore, that i fa] means 
the same thing as a[i). 

Note again that this chapter does not discuss overloaded operators; there is no 
guarantee that i {a]==a [iJ for user-defined types. 2 


@ The use of negative indices is legal, provided the index points into an array. For 


example, 
char v[] = "Marian"; 
char* p = &v(2); 
char ch = p{-2]; 


is a complicated way of assigning ’M’ to ch. 9 


§.2.2 Function Call 


A function call is a postfix expression followed by parentheses containing a possi- 
bly empty, comma-separated list of expressions which constitute the actual argu- 
ments to the function. The postfix expression must be of type “‘function retuming 
T, “pointer to function returning T,” or “‘reference to function retuming T,” and 
the result of the function call is of type “T.” 


@ See also: function declarations (§7.1.2), function definitions (§8.3), linkage (§7.4), 
pointers to functions (§8.2.5), use of temporaries ($12.2, §12.1), overloading resolu- 
tion (§13). O 


When a function is called, each formal argument is initialized (§8.4.3, §12.8, 
§12.1) with its actual argument. Standard (§4) and user-defined ($12.3) conver- 
sions are performed. A function may change the values of its nonconstant formal 
arguments, but these changes cannot affect the values of the actual arguments 
except where a formal argument is of a non-const reference type (§8.2.2). Where 
a formal argument is of reference type a temporary variable is introduced if needed 
(§7.1.6, §2.5, §2.5.4, §8.2.4, §12.2). In addition, it is possible to modify the values 
of nonconstant objects through pointer arguments. 
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A function may be declared to accept fewer arguments (by declaring default 
arguments §8.2.6) or more arguments (by using the ellipsis, ... §8.2.5) than are 
specified in the function definition (§8.3). 

A function can be called only if a declaration of it is accessible from the scope 
of the call. This implies that, except where the ellipsis (...) is used, a formal 
argument is available for each actual argument. 


@ This differs from C in that C allows calling an undeclared function and treats it as 
retuming type int and having unchecked arguments. This is a well known major 
source of errors in C programs. O 


Any actual argument of type float for which there is no formal argument is 
converted to double before the call; any of char, short, enumeration, or a bit- 
field type for which there is no formal argument are converted to int or 
unsigned by integral promotion (§4.1). An object of a class for which no formal 
argument is declared is passed as a data structure. 


m That is, the object is passed without the use of a copy constructor, as described in 
§12.8. O 


An object of a class for which a formal argument is declared is passed by ini- 
tializing the formal argument with the actual argument by a constructor call before 
the function is entered (§12.2, §12.8). 

The order of evaluation of arguments is undefined; take note that compilers 
differ. All side effects of argument expressions take effect before the function is 
entered. The order of evaluation of the postfix expression and the argument 
expression list is undefined. 


m For example, 


int i = 1; 
extern f(int, int); 


void g() 
{ 
f(itt, itt); 


j 


Here, f () is called with the arguments (1,2) or (2,1) or even (1,1) depend- 
ing on the order of evaluation of the arguments. Should f() examine the value of 
the global variable i during the call it would find it to have the value 3 since the 
side effects on the arguments take place before f () is entered. 

It is also possible to have an order dependence between the expression denoting 
the function to be called and the argument list. 
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int i = 1; 
extern int (*p[10]) (int); // array of 10 pointers 
// to functions 


void h() piri 
{ 

(*plit+]) (itt); 
} 


Here, g{1] will be called with the argument 2, or g{2] will be called with the 
argument 1, or g{1] will be called with the argument 1. 

Naturally, such order dependencies should be avoided since they lead to very 
obscure errors. Compilers can detect them and war about them. O 


Recursive calls are permitted. 
m For example, 
int fac(int i) { return 1<i ? i*fac(i-1) : 1; } 


0 


A function call is an lvalue only if the result type is a reference. 


a Given, for example, 


class X { 


the assignment 

£().1 = 17 // error: function returns rvalue 
is invalid. One can, of course, write 

j= f().-i; 


Further, if a function retums a pointer to a class object, assignment to a member of 
that object is legal, as in the following: 


g()->i = 1; 
If an Ivalue is needed as the result of a function call, a reference should be retumed. 


extern int vI]; 


int&é elem(int i) { return v{iJ; } 


void f() 

{ 
int x = elem(7); 
elem(7) = 27; 
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Note that calls such as £().g() are legal when f() returns an object for which 
g() may be called. See §12,2 for an explanation of the lifetime of temporaries gen- 
erated to hold the results of such calls. 

Such constructs are not uncommon. In addition to being written explicitly, they 
often occur where conversion functions (§12.3.1, §12.3.2) are used and also for cer- 
tain styles of overloading (§13). For example, 


class X { 
D hameiets 
public: 
X operatort+ (X); 
X operator* (X); 
}; 


void f() 

( 
X a, D, C, d; 
Lie wae 
a = b*ct+d; 
Pinter 

} 


Here, b*c+d is resolved as b. operator* (c).operator+(d). O 


5.2.3 Explicit Type Conversion 


A simple-type-name (§7.1.6) followed by a parenthesized expression-list constructs 
a value of the specified type given the expression list. If the expression list speci- 
fies more than a single value, the type must be a class with a suitably declared con- 
structor (§8.4, §12.1). 

A simple-type-name (§7.1.6) followed by a (empty) pair of parentheses con- 
structs a value of the specified type. If the type is a class with a suitably declared 
constructor that constructor will be called; otherwise the result is an undefined 
value of the specified type. See also (§5.4). 


m For example, 


class complex { 
Zai a 

public: 
complex (double, double); 
complex (); 

Me 


£() 

{ 
complex z = complex(1,2); 
z = complex (); 
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int i = int(1.2); 
i = int(); 
} 


The last statement assigns an undefined int value to i. O 


5.2.4 Class Member Access 


A postfix expression followed by a dot (.) followed by a name is a postfix expres- 
sion. The first expression must be a class object, and the name must name a 
member of that class. The result is the named member of the object, and it is an 
lvalue if the member is an lvalue. 

A postfix expression followed by an arrow (—>) followed by a name is a postfix 
expression. The first expression must be a pointer to a class object and the name 
must name a member of that class. The result is the named member of the object 
to which the pointer points and it is an lvalue if the member is an Ivalue. Thus the 
expression E1->MOS is the same as (*E1) . MOS. 

Note that ‘‘class objects’’ can be structures (§9.2) and unions (§9.5). Classes 
are discussed in §9. 


m When a member of a union is accessed after a value has been stored in a different 
member of the object, the result will be implementation dependent. No conversion 
will be done between the type of the member by which the value was stored and the 
type of the member by which the value is retrieved. Thys storing a value through a 
member of one type and retrieving it through a member of a different type implies a 
reinterpretation of the bit pattern stored. For example, 
union u_tag { 
int ival; 
float fval; 
} u_obj; 
int i; 


u_obj.fval = 4.0; 

i = u_obj.ival; 
The bit pattem that represents 4.0 as a floating point value on the target machine 
will be stored in u_obj.fval. This bit pattem will be accessed and assigned to 
the integer variable i with no conversion. Naturally, the result is highly implemen- 
tation dependent. O 


5.2.5 Increment and Decrement 


The value obtained by applying a postfix ++ is the value of the operand. The 
operand must be a modifiable Ivalue. The type of the operand must be an arith- 
metic type or a pointer type. After the result is noted, the object is incremented by 
1. The type of the result is the same as the type of the operand, but it is not an 
Ivalue. See also §5.7 and §5.17. 


aay > ot 
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The operand of postfix —— is decremented analogously to the postfix ++ opera- 
tor. 


m A typical use of the increment and decrement operators is to step through an array. 
The example below copies a null-terminated string pointed to by p to a location 
pointed to by q. 


while (*q++ = *pt+) ; 


This code is simpler, but less readable to those unfamiliar with C+ and C, than the 
equivalent code not using the increment operator, which would be 


while (*p != '\0’) { 


sg (H°*p; 
p=pt+i; 
e =2gietat, 
} 
*q = ‘\0'; 


m The increment and decrement operators are no! defined for enumerations; they are 
defined only for other arithmetic types. When applied to an enumeration the value 
of the enumeration is converted to an integer and incremented or decremented. The 
resulting type is an integer, not an enumeration, and cannot be assigned to the 
enumeration. Thus, applying an increment or decrement operation to a variable of 
an enumeration type is an error. For example, 


enum E { a, b=2, c=4, d=8 }; 


void f(E e) 
{ 

ett; // error: integer assigned to enumeration ‘e’ 
} 


5.3 Unary Operators 


Expressions with unary operators group right-to-left. 


unary-expression: 
postfix-expression 
++  unary-expression 
--  unary-expression 
unary-operator cast-expression 
sizeof unary-expression 
sizeof ( hpe-name ) 
allocation-expression 
deallocation-expression 
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unary-operator: one of 
+ 6 fa = aes 


The unary * operator means indirection: the expression must be a pointer, and the 
result is an lvalue referring to the object to which the expression points. If the type 
of the expression is ‘‘pointer to T,” the type of the result is ‘‘T.’’ 

The result of the unary & operator is a pointer to its operand. The operand 
must be a function, an lvalue, or a qualified-name. In the first two cases, if the 
type of the expression is **T,’* the type of the result is ‘‘pointer to T."’ In particu- 
lar, the address of an object of type const T has type const T*; volatile is 
handled similarly. For a qualified-name, if the member is not static and of type 
‘T in class ‘‘C,”’ the type of the result is ‘*pointer to member of C of type T.” 


m Note that the type of a member includes the class in which it was defined (and nor 
any class derived (§10) from that class). For example, 


struct B fivoid f()z int is) }; 
struct D scb f }e 


Here, the types of &B: :f and &D: :f are the same: void (B::+)(). O 


@ Note that the address-of operator must be explicitly used to get a pointer to 
member; there is no implicit conversion of a member name to a pointer to member 
the way there is an implicit conversion of a function name to a pointer to function 
(§4.6, §4.8). Had there been, we would have had an ambiguity in the context of a 
member function. The reason is that within a member function the name of a 
member of that class refers to that member of the specific object for which the 
member function was invoked (§9.3); that is, except when prefixed by the address-of 
Operator, a mention of B::i within B::£() is interpreted as this->i. For 


example, 
void B::f() 
{ 
int B::* p = 6Bs:i7 // ok 
P= Bais // error: ‘B::i’ is an int 
p = &i; // error: ‘&i’ means ‘&this->i’ 
// which is an int* 
int* q = &i; // ok i 
q = Bai // error ‘B::i’ is an int 
g = 6B::i; // error ‘SB::i’ is an int B::* 
} 
o 


For a static member of type T, the type is plain ‘‘pointer to T.’ The address of an 
overloaded function (§13) can be taken only in an initialization or an assignment 
where the left side uniquely determines which version of the overloaded function is 
referred to (§13.3). 
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m When the address of a reference is taken the result is the address of the object 
referred to. 


int i = 1; 
inté r = j; 
int* p = ér; // ‘p’ points to ‘i’ 


o 


m Note also that the address-of operator may be overloaded so the programmer can 
control the meaning of taking the address of an object of a class. O 


The operand of the unary + operator must have arithmetic or pointer type and 
the result is the value of the argument. Integral promotion is performed on integral 
operands. The type of the result is the type of the promoted operand. 


m Unary plus is a historical accident and generally useless. O 


The operand of the unary — operator must have arithmetic type and the result is 
the negation of its operand. Integral promotion is performed on integral operands. 
The negative of an unsigned quantity is computed by subtracting its value from 2”, 
where n is the number of bits in the promoted operand. The type of the result is 
the type of the promoted operand. 

The operand of the logical negation operator ! must have arithmetic type or be 
a pointer; its value is 1 if the value of its operand is 0 and 0 if the value of its 
operand is nonzero. The type of the result is int. 

The operand of ~ must have integral type; the result is the one’s complement of 
its operand. Integral promotions are performed. The type of the result is the type 
of the promoted operand. 


5.3.1 Increment and Decrement 


The operand of prefix ++ is incremented by 1. The operand must be a modifiable 
Ivalue. The type of the operand must be an arithmetic type or a pointer type. The 
value is the new value of the operand; it is an Ivalue. The expression ++x is 
equivalent to x+=1. See the discussions of addition (§5.7) and assignment opera- 
tors (§5.17) for information on conversions. 

The operand of prefix —— is decremented analogously to the prefix ++ operator. 


5.3.2 Sizeof z 


The sizeof operator yields the size, in bytes, of its operand. The operand is 
either an expression, which is not evaluated, or a parenthesized type name. The 
sizeof operator may not be applied to a function, a bit-field, an undefined class, 
the type void, or an array with an unspecified dimension. A byte is undefined by 
the language except in terms of the value of sizeof; sizeof (char) is 1. 
When applied to a reference, the result is the size of the referenced object. 
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m For example, 


struct s ( 
double d1; 
double d2; 
Mae 


s dd; 
s& r = dd; 
int i = sizeof(r); // sizeof(r) >= 2*sizeof (double) 


Note that this implies that the sum of the sizes of the members of a class may be 
larger than the size of the class itself. 


Struct r { 

s& rl; 

s& 12; 

// constructor required; see §12.6.2 
Me 


Here sizeof(r) is probably 2*sizeof(s*), which is most likely less than 
2*sizeof(sé&). 

See §12.6.2 for an explanation of how class members that are references can be 
initialized. O 


When applied to a class, the result is the number of bytes in an object of that class 
including any padding required for placing such objects in an array. 


m A typical example of padding follows: 
struct odd { 
int a; 
char c; 
My 


An odd can theoretically be allocated in sizeof(int)+1 bytes, but most 
machines have an intemal architecture that makes memory references faster when 
integers are placed starting at word boundaries, typically at addresses that are multi- 
ples of two or four. Thus, to avoid (significant) overheads an odd must be allocated 
on such a boundary. To ensure this for all elements in an array of odds the size of 
an odd is typically rounded up to 2*sizeof (int). 

Another form of padding is the ‘housekeeping’ information stored in objects of 
classes with virtual functions (§10.2, §10.7, §10.8) or virtual base classes ($10.5). 
For example, 


class non_trivial : virtual base [ 
virtual f£(); 
MF 


int i = sizeof(non_trivial); PE REER 


The size of a non_trivial will most likely be at least 2*sizeof(int*). O 


The size of any class or class object is larger than zero. 
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m For example, 


struct empty {}; 
int i = sizeof(empty); // i >= 1 


(m 


When applied to an array, the result is the total number of bytes in the array. This 
implies that the size of an array of n elements is n times the size of an element. 


@ Note that the usual conversion of an array to a pointer to its first element does not 
take place when the array is the argument of sizeof. For example, 


int a[10); 
const int i = sizeof(a); // i = 10*sizeof (int) 


o 


The sizeof operator may be applied to a pointer to a function, but not to a 
function. 


@ Note that the usual conversion of a function to a pointer to the function (§4.6) 
does not take place when the array is the argument of sizeof. For example, 


void tO { /* ... */ } 


const int il 
const int i2 


sizeof (áf); // size of pointer to function 
sizeof (f); // error: sizeof (function) 


The result is a constant of type size_t, an implementation-dependent 
unsigned integral type defined in the standard header <stddef .h>. 


5.3.3 New 


The new operator attempts to create an object of the mpe-name (§8.1) to which it 
is applied. This type must be an object type; functions cannot be allocated this 
way, though pointers to functions can. 


allocation-expression: 
i lo new placement, new-lype-name new-initializer op, 
:iop New placement,,, ( type-name ) new-initializer op 
placement: 
( expression-list ) 


new-type-name: 
type-specifier-list new-declarator,,, 
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new-declarator: 
* cv-qualifier-list,,, new-declarator,,, 
class-name :: * cv-qualifier-list,., new-declarator,., 
new-declarator,,, { expression ] 


new-initializer: 
( initializer-list,., ) 


m In general, an allocation-expression must do three things: 
[1] Find storage for the object to be created. 
(2) Initialize that object. 
[3] Return a suitably typed pointer to the object. 
Adjusting the type is purely a compile-time action. O 


The lifetime of an object created by new is not restricted to the scope in which it is 
created. The new operator returns a pointer to the object created. When that 
object is an array, a pointer to its initial element is returned. For example, both 
new int and new int[10] retum an int* and the type of new int [i] [10] 
is int (*) [10]. 


w A reference cannot be created by the new operator. A reference is not an object 
(§8.2.2, §8.4.3), so a pointer to it could not be retumed by new. 0 


Where an array type (§10) is specified all array dimensions but the first must be 
constant expressions (§5.19) with positive values. The first array dimension can be 
a general expression even when the fype-name is used (despite the general restric- 
tion of array dimensions in fype-names to constant-expressions (§5.19)). 

This implies that an operator new() can be called with the argument zero. 
In this case, a pointer to an object is returned. Repeated such calls retum pointers 
to distinct objects. 


m For example, 


void f() 

{ 
char* p = new char; 
char* q = new char; 


if (p==0 I} q==0) { // allocator failed 
abort (); 
} 


if (p == q) { // impossible: ‘p’ must differ from ‘gq’ 
abort (); 
J 
} 


Defining a suitable new_handler (§15) would allow us to eliminate the tests for 
zero retums. O 


The type-specifier-list may not contain const, volatile, class declarations, 





60 Expressions Chapter 5 


or enumeration declarations. 

The new operator will call the function operator new() to obtain storage 
($12.5). A first argument of sizeof (T) is supplied when allocating an object of 
type T. The placement syntax can be used to supply additional arguments. For 
example, new T results in a call of operator new(sizeof(T)) and 
new(2,f) T results in a call operator new (sizeof (T),2,f). 

The placement syntax can be used only provided an operator new() with 
suitable argument types (§13.2) has been declared. 

When an object of a nonclass type (including arrays of class objects) is created 
with operator new, the global :: operator new() is used. When an object of a 
class T is created with operator new, T::operator new () is used if it exists 
(using the usual lookup rules for finding members of a class and its base classes; 
§10.1.1); otherwise the global ::operator new() is used. Using ::new 
ensures that the global ::operator new() is used even if T::operator 
new () exists. 


m The reason that an array of elements of class X isn't allocated by an 
X::operator new () is simply that such an array isn't an X. This has the impor- 
tant side effect that X:: operator new () really can be specialized to be an allo- 
cator for objects of class X and classes derived from X. Had X::operator 
new() been called for arrays, it would have had to be an almost general allocator 
with all the overheads this implies. 0 


m Providing one’s own : :operator new(size_t) is a way of gaining access to 
every (standard) allocation operation. This can be useful in debugging, but is not 
recommended for general programming. The problem is that if two programmers 
make nontrivial changes to the way : :new operates, their programs might not work 
as cooperating parts of a single program without special effort. O 


A new-initializer may be supplied in an allocation-expression. For objects of 
classes with a constructor (§12.1) this argument list will be used in a constructor 
call; otherwise the initializer must be of the form ( expression ) or (). If present, 
the expression will be used to initialize the object; if not, the object will start out 
with an undefined value. 


m For example, 


class complex { 
PEA are 

public: 
complex (double, double); 
IME ISL 

Mi 
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void f() 

{ 
complex* pc = new complex(1,2); 
int* pi = new int(7); 
double* pdl = new double(); 
double* pd2 = new double; 

) 


Here, pe is made to point to a complex object with the initial value 
complex (1,2), pi is made to point to an int with the value 7, and the two 
pointers to double each initialized to point to a double with an undefined value. 

Using empty parameters after the type in a new expression is simply a syntactic 
convenience and has no special meaning. O 


@ Note that the memory retumed by operator new () (see §12.5 and §13.4) need 
not be initialized. In this, it resembles memory allocated on the stack (automatic 
storage). Only static memory has a default initial value, zero (§8.4). O 


If a class has a constructor an object of that class can be created by new only if 
suitable arguments are provided or if the class has a default constructor (§12.1). 
Whether operator new allocates the memory itself or leaves that up to the con- 
structor when creating an object of a class with a constructor is implementation 
dependent. 


m [t will, however, always be allocated without the intervention of the programmer. 
Calling operator new() as pan of the implementation of an allocation- 
expression is the task of the implementation. O 


Access and ambiguity control are done for both operator new() and the con- 
structor; see §12, 

No initializers can be specified for arrays. Arrays of objects of a class with 
constructors can be created by operator new only if the class has a default con- 
structor (§12.1). In that case, the default constructor will be called for each ele- 
ment of the array. 


m Providing a way of specifying arguments for the members of an array would add 
complexity greater than the benefits gained. If a program absolutely must have the 
elements of an array initialized to distinct values, it can often be achieved by pro- 
gramming a default constructor to depend on global information. This is rarely 
worthwhile. D 


Initialization is done only if the value retumed by operator new() is 
nonzero. If the value retumed by the operator new () is 0 (the null pointer) the 
value of the expression is 0. 

The order of evaluation of the call to an operator new() to get memory and 
the evaluation of arguments to constructors is undefined. It is also undefined if the 
arguments to a constructor are evaluated if operator new() retums 0. 





62 Expressions Chapter 5 


m For example, 


void f() 
{ 
2nts2 = 1S 
complex* p = new complex (i++); 


if (p == 0) { 
// allocation failed 
// ‘i’ is either 1 or 2 here 
Ph e 
) 
else { 
// allocation succeeded 
ff SE 282. here 
PI a", 


o 


In a new-type-name used as the operand for new, parentheses may not be used. 
This implies that 


new int (*[10)) (); // error 
is an error because the binding is 
(new int) (*[10}) (); // error 


Objects of general type can be expressed using the explicitly parenthesized version 
of the new operator. For example, 


new (int (*[10])) ()); 


allocates an array of 10 pointers to functions (taking no argument and returning 
int). 

The new-type in an allocation-expression is the longest possible sequence of 
new-declarators. This prevents ambiguities between declarator operators &, *, [], 
and their expression counterparts. For example, 


new int*i; // syntax error: parsed as ‘(new int*) i’ 
// not as ‘(new int) *i’ 


The * is the pointer declarator and not the multiplication operator. 


5.3.4 Delete 
The delete operator destroys an object created by the new operator. 


deallocation-expression: 
tom delete cast-expression 
Zopr delete [ ] cast-expression 


The result has type void. The operand of delete must be a pointer retumed by 
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new. The effect of applying delete to a pointer not obtained from the new 
operator without a placement specification is undefined and usually harmful. Delet- 
ing a pointer with the value zero, however, is guaranteed to be harmless. 


m For example, 


void f() 

{ 
int i; 
int* p = 61; 
delete p; // error 
p = new int[10]; 
ptt; 
delete p; // error 
p = 0; 
delete p; // ok 

} 


In general, catching such bad deletions at compile time is impossible; catching them 
at run time implies time and space overheads. Therefore the results of such dele- 
tions are subtle and usually disastrous. Bad deletions are usually not detected 
immediately, and programs containing them are therefore among the nastiest to 
debug. Almost any effort to avoid such bad deletions is worthwhile. O 


The effect of accessing a deleted object is undefined and the deletion of an 
object may change its value. Furthermore, if the expression denoting the object in 
a delete expression is a modifiable lvalue, its value is undefined after the dele- 
ton. 


m For example, 


void f() 
{ 
int* p = new int; 
if (p == 0) abort(); 
// the value of p is not zero here 
delete p; 
// the value of p may be zero here 


) 


Implementing the delete operator to modify the value of a deleted pointer can be 
useful for debugging by ensuring that a pointer cannot be successfully used after 
being deleted. Without such modification a program might appear to function 
correctly for quite a while, and the inevitable problem could be very difficult to pin- 


point. O 
A pointer to constant cannot be deleted. 


m The reason is that the deletion in principle modifies the object pointed to. For 
example, 
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extern const char * pc; // pointer to constant 


void f() 
{ 


delete pc; // error: pointer to constant 
delete (char*) pc; // I really mean it! 
} 


The purpose of prohibiting the deletion of pointers to constants is to allow program- 
mers to rely on const objects being immutable. For example, 


void h(const int *); // I don't modify my argument 


vold g(int* pi) 
í 

tpi = 1; 

h(pi); 

if (*pi != 1) error("something strange happened"); 
} 


Naturally, this guarantee — like all other guarantees provided by a type system - 
applies only as long as the type system is not deliberately or accidentally broken by 
explicit type conversion, aliasing, compiler errors, or hardware errors. For example, 
no one wants code like this in squirreled away in the system: 


void h(const int * p) // I don’t modify my argument 
{ 
int* q = (int*) p; 
*qtt; // fooled you! 
) 
Without the restriction against deleting pointers to const objects the delete 
operator would have the effect of implicitly removing the const attribute from a 
pointer. No operator should have that property. O 


The delete operator will invoke the destructor (if any, §12.4) for the object 
pointed to. 

To free the storage pointed to, the delete operator will call the function 
operator delete(); see §12.5. For objects of a nonclass type (including 
arrays of class objects), the global ::operator delete() is used. For an 
object of a class T, T: :operator delete () is used if it exists (using the usual 
lookup rules for finding members of a class and its base classes; §10.1.1); other- 
wise the global : :operator delete () is used. Using : :delete ensures that 
the global ::operator delete() is used even if T: :operator delete () 
exists. 

The form 


delete [ ) cast-expression 


is used to delete arrays. The expression points to an array. The destructors (if any) 
for the objects pointed to will be invoked. 
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m The user is required to specify when an array is deleted. The reason for this is to 

avoid requiring the implementation to store information specifying whether a chunk 

of memory allocated by operator new () is an array or not. This can be a minor 

nuisance for the user, but the alternative would imply a difference from the C object = 
layout. This would be a serious incompatibility. In addition, the extra information 

required for each object allocated on the free store could easily increase the space 

overhead significantly. The alternative of making an array into a proper self- 

describing object was also rejected for C compatibility reasons; see §8.2.4. 

Earlier definitions of C++ required users to specify the number of elements in the 
array being deleted; see §18.3. This led to clumsy code and errors, so that burden 
was shifted to the implementations. 

Note that this implies that when new allocates an individual object, the size of 
the object must be stored somewhere. When new allocates an array it must in addi- 
tion store the number of elements in the array. The information thus stored away is 
retrieved and used by the delete operator. O 


m Typically, the distinction between deleting an object and an array of objects is sig- 
nificant only when deleting objects of a class with a destructor. Then, the number of 
objects deleted determines the number of times the destructor must be called. Con- 
sequently, one could consider requiring the delete [J notation only for pointers to 
such classes. Classes that don’t have destructors early in the development of a pro- 
gram, however, may have them added later. Further, a typedef naming a built-in 
type early in the development of a program may later be changed to refer to a class 
with a destructor. Consequently, making a distinction between pointers to classes 
with destructors and pointers to other types is asking for trouble. O 


The effect of deleting an array with the plain delete syntax is undefined, as is 
deleting an individual object with the delete[] syntax. 


m Some trivial cases of deleting an array with the plain delete syntax can be 
detected by the compiler. For example, 


void f() 

{ 
int (*p)(10] = new int[20] [10]; 
delete p; // error 
delete[{] p; // ok 


oO 


m Note that when allocating an individual object of class X a class specific allocator 
may be used. When allocating an array of X objects, the global allocator will be 
used. The proper use of delete and delete[] is essential for deallocation in 
such cases. O 


m The possibility of providing a syntax for using an overloaded operator 
delete () to match the placement syntax for operator new() has repeatedly 
been discussed. One could imagine writing code like this: 
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void* operator new(size_t, Arena*); 
void operator delete(void*, Arena*); // error 


void f(Arena* al) 


{ 
X* pl = new(al) X; 
X* p2 = new X; 
Ives 
delete(al) pl; // error 
delete p2; 
} 


The fundamental objection to this is that whereas in principle all necessary informa- 
tion is available at the point of creation of an object, hardly any is available at the 
point of deletion. Even the exact type of the object pointed to is often lost at the 
point of deletion. It is therefore not sensible to require the programmer to select 
correctly among a variety of deletion operations. Consequently, the feature is feared 
to be error prone. 

A more practical answer is that the added syntax isn’t needed since the problem 
can be solved without it. One solution is to add a virtual function (§10.2) 
my_delete() to class X and call that instead of using delete directly. 


void* operator new(size t, Arena*); 


void f(Arena* al) 


{ 
X* pl = new(al) X; 
X* p2 = new X; 
Nef 
pl->my_delete(al); 
p2->my_delete(0); 
} 
void X::my_delete(Arena* a) 
{ 
this->X::~X(); // explicit call of destructor 
if (a) 
a->free((void*) this); 
else 
delete (void*)this; 
} 


The question is if such use is common enough to warrant the support of a specific 
syntax. O 
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5.4 Explicit Type Conversion 


An explicit type conversion can be expressed using either functional notation 
(§5.2.3) or the cast notation. 


cast-expression: 
unary-expression 
( fNpe-name ) cast-expression 


The cast notation is needed to express conversion to a type that does not have a 
simple-type-name. 


@ Explicit type conversion is often best avoided. Using a cast suppresses the type 
checking provided by the compiler and will therefore lead to surprises unless the 
programmer really was right. Note that a virtual function (§10.2) can often provide 
a type-safe alternative to casting. For example, 


void fl(base* p) /* C style explicit resolution */ 
/* using a type field ei 
{ 
Switch (p->type field) { 
case D: 
do_something with_a_derived((derived*)p); 
HA ass 
} 
) 
void f2(base* p) // C++ style implicit resolution 


// using a virtual function 
{ 
p->do_something(); 
} 


o 
Types may not be defined in casts. 


m For example, 


void f(void* p) 
{ 
(struct s { int a; char* c; })p; // error 


} 


The reason for this restriction is that C+ relies on name equivalence (§9.1) so the 
resulting value couldn’t be used anyway. See also §8.2.5 and §11.4. O 


Any type conversion not mentioned below and not explicitly defined by the user 
(§12.3) is an error. 

Any type that can be converted to another by a standard conversion (§4) can 
also be converted by explicit conversion and the meaning is the same. 

A pointer may be explicitly converted to any integral type large enough to hold 
it. The mapping function is implementation dependent, but is intended to be 
unsurprising to those who know the addressing structure of the underlying machine. 
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A value of integral type may be explicitly converted to a pointer. A pointer 
converted to an integer of sufficient size (if any such exists on the implementation) 
and back to the same pointer type will have its original value; mappings between 
pointers and integers are otherwise implementation dependent. 


m For example, 


char* f(char* p) 
í 

int i = (int)p; 

return (char*)i; // f(arg) == arg ? 
) 


Here, £() may or may not retum a pointer to its argument. It will if and only if 
sizeof (char*)<=sizeof (int). History shows that this is not a wise assump- 
tion to make in software that is intended to be portable. O 


A pointer to one object type may be explicitly converted to a pointer to another 
object type (subject to the restrictions mentioned in this section). The resulting 
pointer may cause addressing exceptions on use if the subject pointer does not refer 
to an object suitably aligned in storage. It is guaranteed that a pointer to an object 
of a given size may be converted to a pointer to an object of the same or smaller 
size and back again without change. Different machines may differ in the number 
of bits in pointers and in alignment requirements for objects. Aggregates are 
aligned on the strictest boundary required by any of their constituents. A void* is 
considered a pointer to object type. 

A pointer to a class B may be explicitly converted to a pointer to a class D that 
has B as a direct or indirect base class if an unambiguous conversion from D to B 
exists ($4.6, §10.1.1) and if B is not a virtual base class (§10.1). Such a cast from 
a base to a derived class assumes that the object of the base class is a sub-object of 
an object of the derived class; the resulting pointer points to the enclosing object of 
the derived class. If the object of the base class is not a sub-object of an object of 
the derived class, the cast may cause an exception. 

The null pointer (0) is converted into itself. : 

A yet undefined class may be used in a pointer cast, in which case no assump- 
tions will be made about class lattices (§10.1). 


m For example, 


class S; 
class T; 


T* £(S* p) { return (T*)p; ) 


Here the type is changed, but the address returned is the address given as the argu- 
ment. This behavior is essential for C compatibility and is usually harmless. With 
incautious use of multiple inheritance, however, it can lead to subtle bugs. For 
example, if these declaration appeared after the definition of £() or in a separate 
translation unit, then a well nigh undetectable error would result from the use of 
£(): 
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class A { int a; J; 
class S { int s; }; 
class T : public A, public S { int t; }; 


Had these declarations been seen, the result of calling £() would be to retum a 
pointer to the T object of which the S object pointed to by £()'s argument is sup- 
posed to be a base. It follows that where multiple inheritance is involved casting to 
and from undefined types is best avoided. O 


An object may be explicitly converted to a reference type X& if a pointer to that 
object may be explicitly converted to an X*. Constructors or conversion functions 
are not called as the result of a cast to a reference. Conversion of a reference to a 
base class to a reference to a derived class is handled similarly to the conversion of 
a pointer to a base class to a pointer to a derived class with respect to ambiguity, 
virtual classes, and so on. 

The result of a cast to a reference type is an Ivalue; the results of other casts are 
not. Operations performed on the result of a pointer or reference cast refer to the 
same object as the original (uncast) expression. 


m For example, 


void f() 
{ 
inti-=l1; 
(float)i = 1.2; // error 
(float&)i = 1.2; // nonportable 
} 


Such uses of casts are often misguided. For example, on an implementation where 
the size of a float differs from the size of an int this construct will not have the 
effect the programmer expected. 
` Reference casts are mostly used to adjust the type of a reference to class objects 
from a base type to a derived type or vice versa. For example, 

Glass B ù Z% oon Ae 

Class D: : public B (>s */ JF 


void f(B& rb) 


{ 
Aria 
D& rd = (D&)rb; // I know rb refers to a D 


TA fa 


o 


A pointer to function may be explicitly converted to a pointer to an object type 
provided the object pointer type has enough bits to hold the function pointer. 


m C+ provides standard conversions from pointers to functions to void* and expli- 
cit conversions from void* to pointers to functions for machines that can support 
such conversions. This differs from ANSI C, which prohibits any conversion 
between a pointer to a function and void*. Classic C provided explicit type 
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Conversion between pointers to functions and pointers to char. It is understood that 
such conversions will be hard — or even impossible - to implement for some 
machines. It was felt that it was better to allow the conversions for the benefit of 
the users of architectures that can support it than to deny it because there are archi- 
lectures for which the implementation is judged to be too hard. O 


A pointer to an object type may be explicitly converted to a pointer to function 
provided the function pointer type has enough bits to hold the object pointer. In 
both cases, use of the resulting pointer may cause addressing exceptions if the sub- 
ject pointer does not refer to suitable storage. 


m Some machine architectures specifically prevent an address from being used for 
both data and code in a single program; others require a system call to change the 
Status from data to code or vice versa. It is not reasonable to require a simple cast- 
to perform such miracles. O 


A pointer to a function may be explicitly converted to a pointer to a function of 
a different type. The effect of calling a function through a pointer to a function 
type that differs from the type used in the definition of the function is undefined. 
See also §4.6. 

An object or a value may be converted to a class object (only) if an appropriate 
constructor or conversion operator has been declared (§12.3). 

A pointer to member may be explicitly converted into a different pointer to 
member type when the two types are both pointers to members of the same class or 
when the two types are pointers to member functions of classes one of which is 
unambiguously derived from the other (§4.6). 


m There is no equivalent to void* for pointers to members. This implies that cast- 
ing of pointers to pointers to members must be used if a generic ‘pointer to any 
member of any class™ is needed. For example, 


typedef void Z::* any _ptom; 


void push_ptom(any_ptom* a); 
any_ptom* pop ptom(); 


void f(int X::* p, double Y::* q) 


{ 
push_ptom((any_ptom*) (&p)); 
push_ptom((any_ptom*) (&q)); 
q = *(double Y::**) pop ptom(); 
p = *(int X::**) pop ptom(); 

) 


Where needed, this ugliness can be suitably disguised or encapsulated. O 


A pointer to an object of a const type can be cast into a pointer to a non- 
const type. The resulting pointer will refer to the original object. An object of a 
const type or a reference to an object of a const type can be cast into a refer- 
ence to anon-const type. The resulting reference will refer to the original object. 
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The result of attempting to modify that object through such a pointer or reference 
will either cause an addressing exception or be the same as if the original pointer or 
reference had referred a non-const object. It is implementation dependent 
whether the addressing exception occurs. 


@ That is, unless the object has been stored in readonly memory the result of having 
cast away const is exactly the same as if the object had never been specified 
const. O 


A pointer to an object of a volatile type can be cast into a pointer to a 
non-volatile type. The resulting pointer will refer to the original object. An 
object of a volatile type or a reference to an object of a volatile type can 
be cast into a reference to a non-volatile type. 


5.5 Pointer-to-Member Operators 


The pointer-to-member operators ->* and .* group left-to-right. 
pm-expression: 
cast-expression 
pm-expression .* cast-expression 
pm-expression ->* cast-expression 


The binary operator .* binds its second operand, which must be of type 
“pointer to member of class T’’ to its first operand, which must be of class T or of 
a class of which T is an unambiguous and accessible base class. The result is an 
object or a function of the type specified by the second operand. 

The binary operator ->* binds its second operand, which must be of type 
“pointer to member of T” to its first operand, which must be of type ‘‘pointer to 
T° or ‘pointer to a class of which T is an unambiguous and accessible base 
class.’ The result is an object or a function of the type specified by the second 
operand. 

If the result of .* or —>* is a function, then that result can be used only as 
the operand for the function call operator (). For example, 


(ptr_to_obj->*ptr_to mfct) (10); 


calls the member function denoted by ptr_to_mfct for the object pointed to by 

ptr_to_obj. 
m Naturally, it would be possible to generalize the notion of a pointer to member to 
allow bound pointers, such as ptr_to_obj->*ptr_to_mfct, to be stored and, 
in general, be treated as first class objects. Doing so, however, would open vast 
opportunities for generalization and language extension in the general area of “what 
is a function and how can J call it?“ and would require implementation techniques 
outside the realm of traditional C techniques. It was felt that restraint was in order. 
o 


The result of an .* expression or a —>* expression is an lvalue if its second 
operand is an lvalue. 
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5.6 Multiplicative Operators 


The multiplicative operators *, /, and $% group left-to-right. 


multiplicative-expression: 
pm-expression 
multiplicative-expression * pm-expression 
multiplicative-expression / pm-expression 
multiplicative-expression % pm-expression 


The operands of * and / must have arithmetic type; the operands of % must 
have integral type. The usual arithmetic conversions (§4.5) are performed on the 
operands and determine the type of the result. 

The binary * operator indicates multiplication. 

The binary / operator yields the quotient, and the binary % operator yields the 
remainder from the division of the first expression by the second. If the second 
operand of / or $ is O the result is undefined; otherwise (a/b) *b + a%b is 
equal to a. If both operands are nonnegative then the remainder is nonnegative; if 
not, the sign of the remainder is implementation dependent. 


m When a division of two integers, using the / operator, is inexact and exactly one 
of the operands is negative, the result is implementation dependent. This result may 
be either the smallest integer greater than the algebraic quotient or the largest integer 
less than the algebraic quotient. Thus, for example, -23/4 will yield either -5 or 
—6. An implementation should specify what the result of such a division will be. 

Similarly, the result of the $ operator, when the division is inexact and exactly 
one of the operands is negative, may be either positive or negative. An implementa- 
tion should specify the sign of such an operation. In either case, the expression 
(a/b) *b + a%b must equal a whenever the quotient a/b is representable on the 
underlying hardware: 

The reason for leaving operator $ partly unspecified is for compatibility with C 
and the wish to enable CH compilers to use the arithmetic operations provided by 
various hardware as directly as possible. O 


5.7 Additive Operators 


The additive operators + and - group left-to-right. The usual arithmetic conver- 
sions (§4.5) are performed for operands of arithmetic type. 
additive-expression: 
multiplicative-expression 
additive-expression + multiplicative-expression 
additive-expression - multiplicative-expression 


The operands must be of arithmetic or pointer type. The result of the + operator is 
the sum of the operands. A pointer to an object in an array and a value of any 
integral type may be added. The result is a pointer of the same type as the original 
pointer, which points to another object in the same array, appropriately offset from 
the original object. Thus if P is a pointer to an object in an array, the expression 
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P+1 is a pointer to the next object in the array. If the resulting pointer points out- 
side the bounds of the array, except at the first location beyond the high end of the 
array, the result is undefined. 


m One can refer to an element beyond the end of an array, but it is still an error to 
dereference such a pointer, 


char a[10]; 
void f() 
í 
char* p = &a[10); // ‘p’ points one past 
// the end of ‘a’ 
if (&a[9] < p) 
Pf TA 
*p = 999; // error: assignment 
// past end of array 
} 


Most implementations are incapable of detecting such errors. O 


The result of the - operator is the difference of the operands. A value of any 
integral type may be subtracted from a pointer, and then the same conversions 
apply as for addition. 

No further type combinations are allowed for pointers. 

If two pointers to objects of the same type are subtracted, the result is a signed 
integral value representing the number of objects separating the pointed-to objects. 
Pointers to successive elements of an array differ by 1. The type of the result is 
implementation dependent, but is defined as ptrdiff_t in the standard header 
<stddef.h>. The value is undefined unless the pointers point to elements of the 
same array; however, if P points to the last element of an array then (P+1)-—1 is 
P. 


m Pointer arithmetic requires a pointer to an object type. Thus the following is ille- 


gal: 

int (*fp) ()=f£; 

fptt; // error: cannot increment pointer to function 
as is this: 

void* p; 

Tie 

ptt; //error: cannot increment pointer to void 


The sizeof (void) is illegal; it logically follows that arithmetic operations on a 
pointer to void are not allowed. O 
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5.8 Shift Operators 


The shift operators << and >> group left-to-right. 


shift-expression: 
additive-expression 
shift-expression << additive-expression 
shift-expression >> additive-expression 


The operands must be of integral type and integral promotions are performed. The 
type of the result is that of the left operand. The result is undefined if the right 
operand is negative, or greater than or equal to the length in bits of the promoted 
left operand. The value of El << E2 is El (interpreted as a bit pattern) left- 
shifted E2 bits; vacated bits are 0-filled. The value of E1 >> E2 is El right- 
shifted E2 bit positions. The right shift is guaranteed to be logical (0-fill) if E1 
has an unsigned type or if it has a nonnegative value; otherwise the result is imple- 
mentation dependent. 


m When the left operand of the >> operator has a signed type and a negative value, 
the result of the operation will be implementation dependent. Either a logical right 
shift (the most significant bits will be filled with zeros) or a signed right shift will be 
done, usually depending on what the target machine does most efficiently. O 


5.9 Relational Operators 


The relational operators group left-to-right, but this fact is not very useful; a<b<c 
means (a<b) <c and not (a<b) && (b<c). 


relational-expression: 
shift-expression 
relational-expression < shift-expression 
relational-expression > shift-expression 
relational-expression <= shift-expression 
relational-expression >= shift-expression 


The operands must have arithmetic or pointer type. The operators < (less than), > 
(greater than), <= (less than or equal to), and >= (greater than or equal to) all yield 
O if the specified relation is false and 1 if it is true. The type of the result is int. 

The usual arithmetic conversions are performed on arithmetic operands. Pointer 
conversions are performed on pointer operands. This implies that any pointer may 
be compared to a constant expression evaluating to 0 and any pointer can be com- 
pared to a pointer of type void* (in the latter case the pointer is first converted to 
void*). Pointers to objects or functions of the same type (after pointer conver- 
sions) may be compared; the result depends on the relative positions of the 
pointed-to objects or functions in the address space. 

Two pointers to the same object compare equal. If two pointers point to non- 
static members of the same object, the pointer to the later declared member com- 
pares higher provided the two members not separated by an access-specifier label 





Section 5.9 Relational Operators 75 


(§11.1) and provided their class is not a union. If two pointers point to nonstatic 
members of the same object separated by an access-specifier label (§11.1) the result 
is undefined. If two pointers point to data members of the same union, they com- 
pare equal. If two pointers point to elements of the same array or one beyond the 
end of the array, the pointer to the object with the higher subscript compares 
higher. Other pointer comparisons are implementation dependent. 


m Comparison of pointers is guaranteed only if the pointers being compared point to 
elements of the same array or one beyond the end of the array. Code that depends 
on comparison of pointers will not be portable. For example, 


int 2[16]; 
int a[{l6]; 
int* zptr=z; 
int* aptr=a; 


if (aptr > zptr) { // not portable 
Tt sites 
} 


One implementation may emit objects in the generated code in the order they appear 
in the source code; another may enter all declared objects in a symbol table, then 
step through the table emitting objects in alphabetical or some other order. The code 
above may execule as the programmer intends when compiled and run on one imple- 
mentation, but may run differently on another implementation. The following code, 
on the other hand, will be portable: 


struct s{ 
int z[16]; 
int a[{16]; 
) arrays; 


int* zptr=arrays.Z; 
int* aptr=arrays.da; 


if (aptr > zptr) { // ok 
JE ees 
) 


The following illustrates another consequence of this definition of pointer com- 
parison that may not be readily apparent: 


static struct Array array [NUM]; 

static struct Array* BegPtr = array; 

static struct Array* EndPtr = éarray[NUM-1]; 
extern struct Array* TestPtr; 


if (TestPtr >= BegPtr && TestPtr <= EndPtr) { 
VE PR 
} 


It is probably intended here that the expression comparing TestPtr with BegPtr 
and with EndPtr will evaluate as true if and only if TestPtr points into array. 
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But C+ defines the result of comparison of pointers only when they point into the 
same array or one beyond. Thus it is not guaranteed that the expression above will 
be false if Test Ptr points outside the array. 

The expression may not evaluate as false on a segmented architecture with 
pointers that address only a single segment when Test Ptr points to something in 
one segment that has the same address within its segment as a member of array 
has in another segment. 

This also explains why addition, subtraction, and comparison of pointers are 
defined only for pointers into an array and one element beyond the end. Originally, 
these operations were defined only for pointers into an array. Users of machines 
with a nonsegmented address space developed idioms, however, that referred to the 
element beyond the end of the array, such as 


int a[100]; 
for (int* p = a; p<éa[100); pt+) ( /* ... */ } 


On such systems addressing beyond the end of an array is harmful only in the 
unlikely event that an array is allocated too close to the highest address in the sys- 
tem. The resulting code, however, was not portable to segmented architectures 
unless special effort was taken. Taking that special effort was deemed feasible and 
worthwhile by the ANSI C committee for one element beyond only. Allowing 
further addressing beyond the end of arrays would be costly and serve few useful 


purposes. O 


5.10 Equality Operators 


equality-expression: 
relational-expression 


equality-expression == relational-expression 

equality-expression != relational-expression 
The == (equal to) and the != (not equal to) operators are exactly analogous to the 
relational operators except for their lower precedence. (Thus a<b == c<d is 1 


whenever a<b and c<d have the same truth-value.) 

In addition, pointers to members of the same type may be compared. Pointer to 
member conversions (§4.8) are performed. A pointer to member may be compared 
to a constant expression that evaluates to 0. 


5.11 Bitwise AND Operator 


and-expression: 
equality-expression 
and-expression & equality-expression 


The usual arithmetic conversions are performed; the result is the bitwise AND func- 
tion of the operands. The operator applies only to integral operands. 
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5.12 Bitwise Exclusive OR Operator 


exclusive-or-expression: 
and-expression 
exclusive-or-expression “ and-expression 


The usual arithmetic conversions are performed; the result is the bitwise exclusive 
OR function of the operands. The operator applies only to integral operands. 


5.13 Bitwise Inclusive OR Operator 


inclusive-or-expression: 
exclusive-or-expression 
inclusive-or-expression | exclusive-or-expression 


The usual arithmetic conversions are performed; the result is the bitwise inclusive 
OR function of its operands. The operator applies only to integral operands. 


5.14 Logical AND Operator 


logical-and-expression: 
inclusive-or-expression 
logical-and-expression && inclusive-or-expression 


The && operator groups left-to-right. It retums 1 if both its operands are nonzero, 
0 otherwise. Unlike &, && guarantees left-to-right evaluation; moreover the second 
operand is not evaluated if the first operand evaluates to 0. 

The operands need not have the same type, but each must have arithmetic type 
or be a pointer. The result is an int. All side effects of the first expression hap- 
pen before the second expression is evaluated. 


5.15 Logical OR Operator 


logical-or-expression: 
logical-and-expression 
logical-or-expression || logical-and-expression 


The || operator groups left-to-right. It retums 1 if either of its operands is 
nonzero, and 0 otherwise. Unlike |, || guarantees left-to-right evaluation; more- 
over, the second operand is not evaluated if the first operand evaluates to nonzero. 

The operands need not have the same type, but each must have arithmetic type 
or be a pointer. The result is an int. All side effects of the first expression hap- 
pen before the second expression is evaluated. 
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5.16 Conditional Operator 


conditional-expression: 
logical-or-expression 
logical-or-expression ? expression : conditional-expression 


Conditional expressions group right-to-left. The first expression must have arith- 
metic type or be a pointer type. It is evaluated and if it is nonzero, the result of the 
conditional expression is the value of the second expression, otherwise that of the 
third expression. All side effects of the first expression happen before the second 
or third expression is evaluated. 

If both the second and the third expressions are of arithmetic type, the usual 
arithmetic conversions are performed to bring them to a common type. Otherwise, 
if both the second and the third expressions are either a pointer or a constant 
expression that evaluates to 0, pointer conversions are performed to bring them to a 
common type. Otherwise, if both the second and the third expressions are refer- 
ences, reference conversions are performed to bring them to a common type. Oth- 
erwise, if both the second and the third expressions are void, the common type is 
void. Otherwise, if both the second and the third expressions are of the same 
class T, the common type is T. Otherwise the expression is illegal. The result has 
the common type; only one of the second and third expressions is evaluated. 


m Note that — as in all other expressions — user-defined conversions ($12.3) will be 
implicitly applied to bring the second and third operands to a common type if a 
common type cannot be found using only standard conversions. O 


The result is an Ivalue if the second and the third operands are of the same type 
and both are lvalues. 


m For example, 


void f(long x) 
{ 
int a,b; 
x?a:b = 1; // ok 


x?x:b = 1; // error: conversion needed to bring 
// ‘x’ and ‘b’ to common type 
// so ‘*x?x:b’ is not an lvalue 


// error: ‘1’ is not an lvalue 
// so X?1:b’ is not an lvalue 


x?1:b 


i] 
H 
` 
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5.17 Assignment Operators 


There are several assignment operators, all of which group right-to-left. All require 
a modifiable Ivalue as their left operand, and the type of an assignment expression 
is that of its left operand. The result of the assignment operation is the value 
stored in the left operand after the assignment has taken place; the result is an 
Ivalue. 


assignment-expression: 
conditional-expression 
unary-expression assignment-operator assignment-expression 


assignment-operator: one of 
= ta f= $= ¢#= -= >m <<a. G= ox |= 


In simple assignment (=), the value of the expression replaces that of the object 
referred to by the left operand. If both operands have arithmetic type, the right 
operand is converted to the type of the left preparatory to the assignment. There is 
no implicit conversion to an enumeration (§7.2), so if the left operand is of an 
enumeration type the right operand must be of the same type. If the left operand is 
of pointer type, the right operand must be of pointer type or a constant expression 
that evaluates to 0; the right operand is converted to the type of the left before the 
assignment. 

A pointer of type T*const can be assigned to a pointer of type T*, but the 
reverse assignment is illegal ($7.1.6). Objects of types const T and volatile 
T can be assigned to plain T Ivalues and to Ivalues of type volatile T; see also 
(§8.4). 

If the left operand is of pointer to member type, the right operand must be of 
pointer to member type or a constant expression that evaluates to 0; the right 
operand is converted to the type of the left before the assignment. 

Assignment to objects of a class (§9) X is defined by the function 
X::operator=() (§13.4.3). Unless the user defines an X::operator=(), 
the default version is used for assignment (§12.8). This implies that an object of a 
class derived from X (directly or indirectly) by unambiguous public derivation 
(§4.6) can be assigned to an X. 


m An object of a base class, however, cannot be assigned to an object of a derived 
class. For example, 


struct S f 
int a; 
j; 


struct SS: S { 
int b; 
le 
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void f (SS xx) 
{ 


S x: 
X = XX; // X.a = xx.a 
XX = x; // error 


o 


A pointer to a member of class B may be assigned to a pointer to a member of 
class D of the same type provided D is derived from B (directly or indirectly) by 
unambiguous public derivation (§10.1.1). 

Assignment to an object of type ‘‘reference to T'’ assigns to the object of type 
T denoted by the reference. 

The behavior of an expression of the form El op= E2 is equivalent to El = 
El op (E2); except that E1 is evaluated only once. In += and -=, the left 
operand may be a pointer, in which case the (integral) right operand is converted as 
explained in §5.7; all right operands and all nonpointer left operands must have 
arithmetic type. 


m Note that operations such as += cannot be applied to variables of enumeration 
types since the result of + is not of an enumeration type (unless overloading has 
been used). For example, 


enum E { a,b,c }; 


void f() 
{ 
E x = b; 
x += c; // error 


For class objects, assignment is not in general the same as initialization (§8.4, 
§12.1, §12.6, §12.8). 


m Assignment differs from initialization for references. 


void f() 
{ 
int i = 1; 
inté r =i; // initialization: ‘r’ refers to ‘i’ 
TIE- 2; // assignment: ‘i’ gets the value ‘2’ 
// through ‘r’ 
} 


For arrays, only initialization is allowed. 
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char a[] = "asdf"; // initialize ‘a’ 
void g{) 
í 
a= "asdf"; // error: no array assignment r 
} 


For other types, the default assignment and initialization operations are identical. 
Assignment and initializations can be defined as separate operations for class types. 
o 


5.18 Comma Operator 


The comma operator groups left-to-right. 


expression: 
assignment-expression 
expression , assignment-expression 


A pair of expressions separated by a comma is evaluated left-to-right and the value 
of the left expression is discarded. All side effects of the left expression are per- 
formed before the evaluation of the right expression. The type and value of the 
result are the type and value of the right operand; the result is an Ivalue if its right 
operand is. 

In contexts where comma is given a special meaning, for example, in lists of 
actual arguments to functions (§5.2.2) and lists of initializers ($8.4), the comma 
operator as described in this section can appear only in parentheses; for example, 


f(a, (t=3, tt+2), c); 


has three arguments, the second of which has the value 5. 


5.19 Constant Expressions 


In several places, C++ requires expressions that evaluate to an integral constant: as 
array bounds (§8.2.4), as case expressions (§6.4.2), as bit-field lengths ($9.6), and 
as enumerator initializers (87.2). 


constant-expression: 
conditional-expression 


A constant-expression can involve only literals (§2.5), enumerators, const values 
of integral types initialized with constant expressions (§8.4), and sizeof expres- 
sions. Floating constants (§2.5.3) must be cast to integral types. Only type conver- 
sions to integral types may be used. In particular, except in sizeof expressions, 
functions, class objects, pointers, and references cannot be used. The comma 
operator and assignment-operators may not be used in a constant expression. 























Statements 


This chapter discusses statements, which control the execution sequence of pro- 
grams. 


CH provides statements for conditional execution (if and switch) and itera- 
tion (do, for, and while). The break, continue, return, and goto 
statements transfer control in a CH program. Other statements evaluate an 
expression (the expression statement) or do nothing (the null statement). State- 
ments may be grouped in {} pairs to form compound statements. 


A declaration is a statement in C+; declarations are introduced in this chapter 
and discussed in detail in the following two chapters. 


6 Statements 


Except as indicated, statements are executed in sequence. 


Stalement: 
labeled-statement 
expression-statement 
compound-statement 
selection-statement 
iteration-statement 
jump-statement 
declaration-statement 


m CH adopts C’s notion of a statement with little change. The main difference is 
that in CH declarations need not be placed before statements in a block, but can be 
introduced where first needed. This idea and the style of programming that goes 
with it was inspired by Algol68. The most important use of declarations not at the 
start of a block is to postpone the introduction of a variable to the point where one 
has a value with which to initialize it. This use minimizes errors due to uninitialized 





— 
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variables. O 


6.1 Labeled Statement 
A statement may be labeled. 


labeled-statement: 
identifier : statement 
case constant-expression : Statement 
default : statement 


An identifier label declares the identifier. The only use of an identifier label is as 
the target of a goto. The scope of a label is the function in which it appears. 
Labels cannot be redeclared within a function. A label can be used in a goto 
Statement before its definition. Labels have their own name space and do not inter- 
fere with other identifiers. 

Case labels and default labels may occur only in switch statements. 


6.2 Expression Statement 
Most statements are expression statements, which have the form 


expression-statement: 
EXPFESSION op i 


Usually expression statements are assignments or function calls. All side effects 
from an expression statement are completed before the next statement is executed. 
An expression statement with the expression missing is called a null statement; it is 
useful to carry a label just before the } of a compound statement and to supply a 
null body to an iteration statement such as while (§6.5.1). 


6.3 Compound Statement, or Block 


So that several statements can be used where one is expected, the compound state- 
ment (also, and equivalently, called **block’’) is provided. 


compound-statement: 
{ statement-list,,, } 


statement-list: 
Statement 
Statement-list statement 


Note that a declaration is a statement (§6.7). 
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6.4 Selection Statements 


Selection statements choose one of several flows of control. 


Selection-statement: 
if ( expression ) statement 
if ( expression ) statement else statement 
switch ( expression ) statement 


The statement in a selection-statement may not be a declaration. 


E If a declaration could be the only statement after if or else, it would introduce 
a name of uncertain scope and definite uselessness. For example, 


if (i) 
int a= 7; // error: declaration as only statement 
// after ‘if’ 
else 
int b = 8; // error: declaration as only statement 
// after ‘else’ 


6.4.1 The if Statement 


The expression must be of arithmetic or pointer type or of a class type for which an 
unambiguous conversion to arithmetic or pointer type exists (§12.3). 

The expression is evaluated and if it is nonzero, the first substatement is exe- 
cuted. If else is used, the second substatement is executed if the expression is 
zero. The else ambiguity is resolved by connecting an else with the last 
encountered else-less if. 


6.4.2 The switch Statement 


The switch statement causes control to be transferred to one of several statements 
depending on the value of an expression. 

The expression must be of integral type or of a class type for which an unambi- 
guous conversion to integral type exists (§12.3). Integral promotion is performed. 
Any statement within the statement may be labeled with one or more case labels as 
follows: 


case constant-expression 


where the constant-expression (§5.19) is converted to the promoted type of the 
switch expression. No two of the case constants in the same switch may have the 
same value. 

There may be at most one label of the form 


default : 


within a switch statement. 


+ 
a 

7 

% 





86 Statements Chapter 6 


m A case label need not be at the highest level of scope within a switch statement. 
For example, 


switch (i) { 


case 1: 
{ 
hi Pe Be 
case 2: 
{ 
ERSE 
case 3: 
{ 
(Ee 
) 
) 
} 


Fortunately, people do not in general write such code. Machines, however, occa- 
sionally have good reasons for generating code like that. O 


Switch statements may be nested; a case or default label is associated with 
the smallest switch enclosing it. 

When the switch statement is executed, its expression is evaluated and com- 
pared with each case constant. If one of the case constants is equal to the value of 
the expression, control is passed to the statement following the matched case label. 
If no case constant matches the expression, and if there is a default label, con- 
trol passes to the statement labeled by the default label. If no case matches and if 
there is no default then none of the statements in the switch is executed. 

case and default labels in themselves do not alter the flow of control, 
which continues unimpeded across such labels. To exit from a switch, see break, 
§6.6.1. 


Usually, the statement that is the subject of a switch is compound. 


m It does not have to be a compound statement, though. For example, 
switch (i) case 1: cout << "!!!\n"; 

is simply a confusing way of saying 
if (i == 1) cout << "!!!\n"; 


o 


Declarations may appear in the statement of a switch-statement. It is illegal, how- 
ever, to jump past a declaration with an explicit or implicit initializer unless the 


declaration is in an inner block that is not entered (that is, completely bypassed by 
the transfer of control; §6.7). 


m For example, 
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switch (i) 
int vl 
case 1: 
int v2 
IM ane 
case 2: 
1f (v2 == 7) // error: jump past initialized variable 
TIS 5550 


~ 


2; // error: jump past initialized variable 


33 


This implies that declarations that contain explicit or implicit initializers must be 
contained in an inner block. 


6.5 Iteration Statements 


Iteration statements specify looping. 


iteration-statement: 
while ( expression ) statement 
do Statement while ( expression ) ; 
for ( for-init-statement Expression, ¢ expression... ) Statement 


for-init-statement. 
expression-statement 
declaration-statement 


Note that a for-init-statement ends with a semicolon. 
The statement in an iteration-statement may not be a declaration. 


6.5.1 The while Statement 


In the while statement the substatement is executed repeatedly until the value of 
the expression becomes zero. The test takes place before each execution of the 
statement. 

The expression must be of arithmetic or pointer type or of a class type for 
which an unambiguous conversion to arithmetic or pointer type exists (§12.3). 


6.5.2 Do statement 


In the do statement the substatement is executed repeatedly until the value of the 
expression becomes zero. The test takes place after each execution of the state- 
ment. 

The expression must be of arithmetic or pointer type or of a class type for 
which an unambiguous conversion to arithmetic or pointer type exists ($12.3). 
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6.5.3 The for Statement 
The for statement 


for ( for-init-statement expression-1 expression-2,,, ) statement 


opt * 


is equivalent to 


for-init-statement 

while ( expression-] ) { 
statement 
expression-2 ; 


) 


except that a continue in statement will execute expression-2 before re- 
evaluating expression-]. Thus the first statement specifies initialization for the 
loop; the first expression specifies a test, made before each iteration, such that the 
loop is exited when the expression becomes zero; the second expression often 
specifies incrementing that is done after each iteration. The first expression must 
have arithmetic or pointer type or a class type for which an unambiguous conver- 
sion to arithmetic or pointer type exists (§12.3). 

Either or both of the expressions may be dropped. A missing expression-1 
makes the implied while clause equivalent to while (1). 


m For example, a common idiom for an infinite loop is 
for (irh // s- 


Similarly, loops with more than one exit point or more than one exit condition are 
often written like this: 


for(s7) { 
Shs 
TEV fn */. ) breaks 


Afo LE So 8/2) (DreaK? 


If the for-init-statement is a declaration, the scope of the names declared 
extends to the end of the block enclosing the for-statement. 


m There is no special scope rule for a name declared in the initializing statement ina 
for-statement. This implies that the scope of such a name extends to the end of the 
block enclosing the for-statement. For example, 


sea 
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for (int i = 0; i<100; i++) f 
Lance 
break; 

} 


if (i<100) // ‘i’ is still in scope 


G 


The absence of a special rule implies that the same name cannot be used to control 
two for loops in the same scope. 


for (int i = 0; i<100; i++) { 


VI ever 

} 

for (int i = 0; 1<100; i++) { // error: ‘i’ defined twice 
TF Sas 


} 


In such cases, the second loop variable must either be renamed or not be redeclared 
in the for-statement. 

On balance, it would probably have been better to introduce a special rule to 
limit the scope of a name introduced in the initializing statement of a for-statement 
to the for-statement, but much code now exists that depends on the general rule. 

One could also observe that features making it easier to write large functions 
may be the kind of local convenience for which one pays a price in overall program 
structure. A major feature of the C+ class concept is that it can be used to cut the 
average size of functions significantly. O 


6.6 Jump Statements 
Jump statements unconditionally transfer control. 


jump-statement: 
break ; 
continue ; 
return expression, ; 
goto identifier ; 


On exit from a scope (however accomplished), destructors (§12.4) are called for 
all constructed class objects in that scope that have not yet been destroyed. This 
applies to both explicitly declared objects and temporaries ($12.2). 


6.6.1 The break Statement 


The break statement may occur only in an iferation-statement or a switch state- 
ment and causes termination of the smallest enclosing iteration-statement or 
switch statement; control passes to the statement following the terminated state- 
ment, if any. 
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6.6.2 The continue Statement 


The continue statement may occur only in an iteration-statement and causes 
control to pass to the loop-continuation portion of the smallest enclosing iteration- 
Statement, that is, to the end of the loop. More precisely, in each of the statements 


while (foo) { do { LOK) e | 

Dd eens Liles // 
CONtAto: contin: ; contin: ; 
) } while (foo); ) 


a continue not contained in an enclosed iteration statement is equivalent to 
goto contin. 


6.6.3 The return Statement 


A function retums to its caller by the return statement. 

A retum statement without an expression can be used only in functions that do 
not retum a value, that is, a function with the return value type void, a constructor 
(§12.1), or a destructor (§12.4). A retum statement with an expression can be used 
only in functions retuming a value; the value of the expression is returned to the 
caller of the function. If required, the expression is converted, as in an initial- 
ization, to the return type of the function in which it appears. This may involve the 
construction and copy of a temporary object (§12.2). Flowing off the end of a 
function is equivalent to a return with no value; this is illegal in a value- 
retuming function. 


m Note that returning a value of a class with a default constructor is not equivalent 
to returning no value. 


class X { 
Ih BEA 
public: 
X(); 
MF 
X £() 
{ 
Li rans 
return; // error: return value expected 
) 
X g() 
{ 
A 


return X(); // ok 


waca 
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6.6.4 The goto Statement 


The goto statement unconditionally transfers control to the statement labeled by 
the identifier. The identifier must be a label (§6.1) located in the current function. 


6.7 Declaration Statement 


A declaration statement introduces a new identifier into a block; it has the form 


declaration-statement: 
declaration 


If an identifier introduced by a declaration was previously declared in an outer 
block, the outer declaration is hidden for the remainder of the block, after which it 
resumes its force. 

Any initializations of auto or register variables are done each time their 
declaration-statement is executed. Destruction of local variables declared in the 
block is done on exit from the block (§6.6). Destruction of auto variables defined 
in a loop is done once per iteration. For example, here the Index j is created and 
destroyed once each time round the i loop: 


for (int i = 0; 1i<100; i++) 
for (Index j = 0; j<100; j++) { 
// 
) 


Transfer out of a loop, out of a block, or back past an initialized auto variable 
involves the destruction of auto variables declared at the point transferred from 
but not at the point transferred to, 

It is possible to transfer into a block, but not in a way that causes initializations 
not to be done. It is illegal to jump past a declaration with an explicit or implicit 
initializer unless the declaration is in an inner block that is not entered (that is, 
completely bypassed by the transfer of control) or unless the jump is from a point 
where the variable has already been initialized. For example, 


void f() 
{ 
1, 3 
goto lx; // error: jump past initializer 


Bh Se 
ly: 


1x: 
goto ly; // ok, jump implies destructor 
// call for ‘a’ 
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m C has no such restriction. Typically, that is no advantage to the programmer since 
it simply allows code that unintentionally depends on undeclared variables. This 
alone would not have been reason enough for CH to disallow a valid C construct. 
In CH, however, the destruction of a variable that has not been constructed is usu- 
ally a disaster and must be avoided. Since destructor calls are implicit, even the 
case where a variable is never used on a path where its initialization was bypassed 
would end in disaster and must be outlawed. 

One might have allowed jumping past variables without destructors and not past 
variables with destructors. This would, however, have broken the principle that 
there should be no fundamental differences in the use of user-defined and built-in 
types, with only the doubtful benefit of allowing a traditional class of errors. O 


An auto variable constructed under a condition is destroyed under that condition 
and cannot be accessed outside that condition. For example, 


Lf, (3) 
for (int j = 0; j<100; j++) { 
// 
} 
if (j!=100) // error: access outside condition 
// 


m After all, i might have been 0. O 


Initialization of a local object with storage class static (§7.1.1) is done the 
first time control passes through its declaration (only). Where a static variable 
is initialized with an expression that is not a constant-expression, default initial- 
ization to 0 of the appropriate type (§8.4) happens before its block is first entered. 


@ This makes recursive and mutually recursive function calls used in the initializers 
well-defined. Consider this beauty: 


int foo(int i) 

{ 
static int s = foo(2*i): // recursive call 
return i+l; 


} 


A first call of foo, foo (3) will yield the result 4 and leave foo'’s s with the 
value 7. The reason is that in the second call of foo (), s is considered initialized 
even though it has not yet been updated with the value in the first call of foo. 
These semantics can be implemented by a simple first time switch. O 


The destructor for a local static object will be executed if and only if the 
variable was constructed. The destructor must be called either immediately before 
or as part of the calls of the atexit () functions (§3.4). Exactly when is unde- 
fined. 
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6.8 Ambiguity Resolution 


There is an ambiguity in the grammar involving expression-statements and 
declarations: An expression-statement with a function-style explicit type conversion 
(§5.2.3) as its leftmost subexpression can be indistinguishable from a declaration 
where the first declarator starts with a (. In those cases the statement is a 
declaration. 

To disambiguate, the whole statement may have to be examined to determine if 
it is an expression-statement or a declaration. This disambiguates many examples. 
For example, assuming T is a simple-type-name (§7.1.6), 


T(a)->m = 7; // expression-statement 
T(a)++; // expression-statement 
T(a,5)<<c; // expression-statement 


T(*d) (double(3)); // expression-statement 


T(*e) (int); // declaration 
T(f) (); // declaration 
LAG): Lee: hig // declaration 


The remaining cases are declarations. For example, 


T(a); // declaration 
T(*b) (); // declaration 
T(c)=7; // declaration 


T(d),e, £=3; // declaration 
T(g) (h,2); // declaration 


The disambiguation is purely syntactic; that is, the meaning of the names, 
beyond whether they are type-names or not, is not used in the disambiguation. 


@ Note that a simple lexical lookahead can help a parser disambiguate most cases. 
Consider analyzing a statement consisting of a sequence of tokens as follows: 


type-name ( d-or-e ) tail 


Here, d-or-e must be a declarator, an expression, or both for the statement to be 
legal. This implies that rail must be a semicolon, something that can follow a 
parenthesized declarator or something that can follow a parenthesized expression, 
that is, an initializer, const, volatile, (, [, or a postfix or infix operator. 

The general cases cannot be resolved without backtracking, nested grammars or 
similar advanced parsing strategies. In particular, the lookahead needed to disambi- 
guate this case is not limited. 

In a parser with backtracking the disambiguating rule can be stated very simply: 

[1] If it looks like a declaration, it is; otherwise 

[2] if it looks like an expression, it is; otherwise 

[3] it is a syntax error. 

A user can explicitly disambiguate cases that appear obscure. For example, 
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void f() 
{ 
auto int(*p)();  // explicitly declaration 
(void) int(*p) (); // explicitly expression-statement 


0, int (*p) (); // explicitly expression-statement 
(int (*p) ()); // explicitly expression-statement 
int (*p) (); // resolved to declaration 


o 


A slightly different ambiguity between expression-statements and declarations is 
resolved by requiring a type-name for function declarations within a block (§6.3). 
For example, 


void g() 
{ 
int £(); // declaration 
int a; // declaration 
f(); // expression-statement 


a; // expression-statement 

















Declarations 


A declaration introduces one or more names into a program and specifies how 
those names are to be interpreted. A declaration can specify a storage class, 
type, and linkage for an object or function. It can also provide the definition of 
a function or an initial value for an object. A declaration can give a name to a 
constant (enumeration declaration), declare a new type, or specify a synonym for 


a type. Inline functions, const, volatile, and the provision of type-safe 
linkage are discussed. 


7 Declarations 


Declarations specify the interpretation given to each identifier; they do not neces- 
sarily reserve storage associated with the identifier (§3.1). Declarations have the 
form 


declaration: 
decl-specifterS op declarator-list,, i 
asm-declaration 
function-definition 
linkage-specification 


The declarators in the declarator-list (§8) contain the identifiers being declared. 
Only in function definitions (§8.3) and function declarations may the decl-specifiers 
be omitted. Only when declaring a class ($9) or enumeration (§7.2), that is, when 
the decl-specifier is a class-specifier or enum-specifier, may the declarator-list be 
empty. asm-declarations are described in §7.3, and linkage-specifications in §7.4. 
A declaration occurs in a scope (§3.2); the scope rules are summarized in §10.4. 
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7.1 Specifiers 


The specifiers that can be used in a declaration are 


decl-specifier: 
storage-class-specifier 
type-specifier 
fet-specifier 
template-specifier 
friend 
typedef 


decl-specifiers: 
decl-specifiers,., decl-specifier 


m Most declarations introduce a name. The exception is a declaration of an 
unnamed bit-field in a structure (§9.6). 


struct s { 
VAD 
ant ee // two bit field 
Alis 
J; 
Unnamed fields are occasionally used for padding to match an externally imposed 
layout and therefore need no name. Leaving the name out of other declarations is an 
error. For example, 


static char; // error: name expected 
extern int; // error: name expected 


The name introduced need not be the name of an object or a function. 


class C; // introduce a class name 
typedef int I; // introduce a synonym for ‘int’ 


o 


The longest sequence of decl-specifiers that could possibly be a type name is 
taken as the decl-specifiers of a declaration. The sequence must be self-consistent 
as described below. For example, 


typedef char* Pc; 
static Pc; // error: name missing 


Here, the declaration static Pc is illegal because no name was specified for the 
static variable of type Pc. To get a variable of type int called Pc, the type- 
specifier int must be present to indicate that the typedef-name Pc is the name 
being (re)declared, rather than being part of the decl-specifier sequence. For exam- 
ple, 


void f(const Pc); // void £(char*const) 
void g(const int Pc); // void g(const int) 
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Note that since signed, unsigned, long, and short by default imply 
int, a typedef-name appearing after one of those specifiers must be the name 
being (re)declared. For example, 


void h(unsigned Pc); // void h(unsigned int) 
void k(unsigned int Pc); // void k(unsigned int) 


@ Note that the subtleties to do with whether an identifier is a use of a name of a 
type or a redefinition of that name stems from the ability to leave the name of a type 
out of a declaration and have it default to int (§7.1.6). If in doubt, don't use 
implicit ints. O 


7.1.1 Storage Class Specifiers 
The storage class specifiers are 


storage-class-specifier: 
auto 
register 
static 
extern 


The auto or register specifiers can be applied only to names of objects 
declared in a block (§6.3) and for formal arguments (§8.3). The auto declarator is 
almost always redundant and not often used; one use of auto is to distinguish a 
declaration-statement from an expresston-statement (§6.2) explicitly. 


m The compiler knows that 
int (*p) [5]; 


is the declaration of a pointer to an array of five integers, but decorating the declara- 
tion with a redundant auto may help a human reader. 


auto int (*p) [5]; 


It might also help the human writer who does not wish to be a language lawyer. O 


A register declaration is an auto declaration, together with a hint to the 
compiler that the variables declared will be heavily used. The hint may be ignored 
and in most implementations it will be ignored if the address of the variable is 
taken. 


m Unlike C, C+ allows taking the address of an object declared to have storage class 
register. The following, therefore, is legal CH but not legal C: 


register i; 
int* ip = éi; // C++, but not C 
If such a sequence appears, the object must be allocated in storage for which an 


address can be represented. 
One reason for this difference is that compiler technology has progressed to the 
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point where the register hint is often more trouble than it is worth. Another rea- 
son is that in CH variables are often objects of classes with associated operations. 
Leaving register as more than a simple hint to the compiler could hinder both 
portability and optimization. O 


An object declaration is a definition unless it contains the extern specifier 
and has no initializer (§3.1). 


A definition causes the appropriate amount of storage to be reserved and any 
appropriate initialization (§8.4) to be done. 


The static and extern specifiers can be applied only to names of objects 
and functions. 


@ In particular, 


static class X { // error 
int a; 
TIA more 

}: 

typedef static int sint; // error 


are illegal. O 


There can be no static function declarations within a block, nor any static or 
extern formal arguments. Static class members are described in (§9.4); extern 
cannot be used for class members. 

A name specified static has intemal linkage. 


m The word ‘‘static’’ has two basic meanings in C and Ch. One is ‘‘allocated once 
at a fixed address” (as opposed to allocated on the stack once per function call); the 
other is ‘‘local'’ (as in local to a translation unit or ‘‘in class scope’’). These two 
meanings interact and frequently cause confusion. O 


Objects declared const have internal linkage unless they have previously been 
given external linkage. A name specified extern has external linkage unless it 
has previously been given internal linkage. A file scope name without a storage- 
class-specifier has external linkage unless it has previously been given internal link- 
age and provided it is not declared const. For a nonmember function an 
inline specifier is equivalent to a static specifier for linkage purposes (§3.3). 
All linkage specifications for a name must agree. For example, 


static char* £(); // £() has internal linkage 


char* £() // £() still has internal linkage 
{0 / Riera jt) 
char* g(); // g() has external linkage 


static char* g() // error: inconsistent linkage 
{o/s ke JE) 


Section 7.1.1 Storage Class Specifiers 99 


static int a; // ‘a’ has internal linkage 

int a; // error: two definitions 

static int b; // `b' has internal linkage 
extern int b; // `“b' still has internal linkage 
int Cz // ‘c' has external linkage 
static int c; // error: inconsistent linkage 
extern d; // ‘d’ has external linkage 
static int d; // error: inconsistent linkage 


S These rules for the use of extern and static and declarations without explicit 
extern or static are the strictest possible given existing code and the ANSI C 
rules. The weak specification of extern and static in the original specification 
of C led to serious differences among C dialects. This became a major source of 
confusion and portability problems. People who find the C+ rules overly strict are 
encouraged to remember that. We have even more sympathy with people who find 
the C+ rules not quite strict enough, but encourage them to remember that every 
tightening of the rules breaks somebody's code. O 


The name of an undefined class can be used in an extern declaration. Such a 
declaration, however, cannot be used before the class has been defined. For exam- 


ple, 


struct S; 

extern S a; 
extern S £(); 
extern void g(S); 


void h() 
{ 
g(a); // error: S undefined 
a GE // error: S undefined 
) 


7.1.2 Function Specifiers 
Some specifiers can be used only in function declarations. 
fet-specifier: 
inline 
virtual 
The inline specifier is a hint to the compiler that inline substitution of the 
function body is to be preferred to the usual function call implementation. The hint 
may be ignored. For a nonmember function inline specifier also gives the func- 
tion default internal linkage (§3.3). 
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m Inlining does not affect the meaning of a function call. In this, inlining differs 
from macro expansion. An inline function has the usual function definition syntax 
and obeys all the usual scope and type checking rules. Inlining is simply a different 
implementation technique for function calls. Instead of generating code transferring 
control and passing arguments to a single copy of the function's code, a suitably 
modified copy of the function's code replaces the call. Inlining saves the time 
needed for the transfer of control (both there and back again) including the time 
needed to save and restore registers, copy arguments, and so on. Once inlined, the 
code of a function becomes available to optimizers that would otherwise not optim- 
ize across a function call boundary. 

Note that arguments may have to be copied to avoid changing the meaning of a 
function call even when inlining is used. 

For comparison, consider the following roughly equivalent pair of a macro and 
an inline function: 


double old a; 
#define DBL(a) ((old_a=a), ((a)+{a))) 
inline int dbl(int a) { old_a = a; return ata; } 


The most obvious difference is that the function has the usual function definition 
syntax and has its type defined. It can be used like this 


void f(int* pi, char* pc) 


{ 

double old a = 7; // hides global ‘old_a’ 

(Ph e 

old a = dbl (*pi++); 

old a = dbl (pc); // error: argument type mismatch 
} 


and the correct call will expand to something like 


int tmp; 
old a = ( (tmp=*pit+t), (::old_a=tmp), (tmp+tmp)); 


The temporary tmp is introduced to ensure that the argument expression is evaluated 
only once and that the variable old_a used in db1 () is bound to the global vari- 
able of that name. 

Consider, in contrast, 


void f(int* pi, char* pc) 


{ 
double old a= 7; // hides global 'old a’ 
IA baie 
old_a = DBL(*pitt); 
old_a = DBL(pc); // errors on expansion 
} 


macro-expands into 
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void f(int* pi, char* pc) 


{ 
double old a= 7; // hides global ‘old_a’ 
eine 
old_a = ((old_a=*pi+t), ((*pit+)+(*pitt))); 
old_a = ((old_a=pc), ((pc)+(pc))); // error 


) 


merrily evaluating the argument expression three times per call and referring to the 
local copy of old_a. The second expansion caused two compiler errors: one for 
adding pointers and one for assigning a char* to a double. Neither will seem 
particularly obvious to a programmer who simply called DBL (). 

Sometimes the behavior of the macro is just what is needed, but often the differ- 
ences from the behavior of functions cause time consuming surprises to the program- 
mer. The property of macros that is most often useful — compared with inline func- 
tions — is their ability to operate on any type of argument. This advantage can be 
partially offset by the use of virtual functions (§10.2) and templates (§14). Tem- 
plates also partially offset the advantage that occasionally can be gained from macros 
with arguments that are not expressions. O 


B Consider when to specify an inline function. Since inlining is purely an optimiza- 
tion, it should be used only when the benefit-in run-time or space outweighs the 
costs and inconveniences imposed by its use. 

For all but the simplest functions, the time spent in a call is dominated by the 
lime it takes to execute the function and not the cost of calling it. This implies that 
the saving from inlining any but the simplest functions is minimal. Further, there 
can be a space cost from inlining; if the size of the code generated by inlining is 
larger than the code used in the function call sequence, a net loss of space is 
incurred, This can be noticeable when a function is called in many places. On the 
other hand, the code generated for a really minuscule function can be smaller than 
the function call sequence, so one can achieve a gain in time and space. The ideal 
candidate for inlining is a function that does something really simple such as retum- 
ing a value, incrementing a value, or calling another function. Such functions proli- 
ferate where data hiding is used. For example, 


class account { 
int sum; 
GN =e 
public: 
int balance(} { return sum; } 
int withdraw(int x) { return sum-=x; } 
A 
}; 


Such tiny functions are obvious candidates for inlining. A useful rule of thumb is 
that inline functions consisting of one or two simple expressions are good candidates 
for inlining. 

There are functions for which inlining is a guaranteed win. That is, they 
decrease the size of the generated code and increase the execution speed even on 
machines with fast, compact function calls. This is the kind of function that simply 
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performs type conversions so the expanded code for the function is just a call to 
another function decorated with a few type conversions. For example, 


class pXvector : public pvector { 
Aas 


X& operator[] (int i) 


{ return (X&) pvector::operator[] (i); } 
i; 


Note that inlining isn’t a panacea. Ít can easily be overused. For example, the 
definition of an inline function has to be available for inlining to be done. This 
implies that all callers of an inline function must be recompiled if its definition 
changes; the usual function call implementation protects users against that. Occa- 
sionally, it can also be a problem that inlining exposes implementation details in 
header files where every user can read them. O 


m Note that the order of evaluation of actual arguments to functions is undefined 
(§5.2.2). In particular, an inline expansion is not required to preserve the order of 
evaluation of actual arguments that the implementation would have produced for an 
out-of-line function call. Since one call of a function in a program may be inlined 
while another call is handled by the normal function call mechanism this can lead to 
two calls of the same function with identical actual arguments yielding different 
results. Relying on the order of evaluation of function arguments is ill-advised. O 


@ As stated, a compiler is free to ignore the hint to inline a function. It is necessary 
to allow a compiler to ignore that hint. Determining whether a function can be 
inlined or not is in general not possible. Consider, for example, an inline function 
that either calls itself recursively or returns based on the result of an input operation. 


#include <iostream.h> 


inline void f{) 
{ 

char ch = 0; 

if (cin>>ch && ch!='q’) f(); 
} 


Naturally, when not all invocations of a function are expanded inline, a callable ver- 
sion of the function must be generated. Further, such a version must be generated if 
the address of an inline function is taken. A call of an inline function through a 
pointer to function typically results in a noninlined call. 

Ordinary calls may be generated for inline functions for more mundane reasons. 
For example, 

— An inline function was too large for inlining to be worthwhile. 

— An inline function was recursive. 

— An inline function was invoked in a program before it was defined. 

— An inline function was invoked twice within an expression. 

— An inline function contained a loop, a switch, or a goto. 

Limitations on inlining will vary from implementation to implementation, The 
limitations above are the ones found in the original C++ implementation. It is easy 
to do better. 


F 
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The original C+ implementation limited inlining to at most one call of a single 
inline function per expression . This simple technique avoids trouble with recursion 
and — most important — minimizes the use of temporary variables so that inlining 
can be used on machines with limited stack space. 

What is worthwhile to inline depends critically on the application, the C+ imple- 
mentation, and the hardware on which the application is to run. One could imagine 
a machine for which inlining was never worthwhile because function call was blind- 
ingly fast. It is also easy to imagine a machine for which certain forms of inlining 
are unusually important. For example, on a machine with special hardware for vec- 
tor operations outlining a function because it contained a loop might be exactly the 
wrong thing to do since the loop might be much Jess expensive than a function call. 
Implementers should, of course, always be sensitive to the needs of their users, but it 
is probably worthwhile to pay special attention to uses of inlining. O 


m One might claim that a clever enough compiler could do as well or better without 
the inline hint. This was, after all, the argument used to make register (just) 
a hint. First, inline already is a hint. Its only semantic effect is to give the func- 
lion a particularly weak form of internal linkage — the peculiarity is that an inline 
member function is not allowed to have two different definitions in two different 
translation units (§3.3). Second, it was a distinct advantage that C allowed the pro- 
grammer to provide the register hint. For almost fifteen years there was no 
compiler ‘‘smart enough” to make register redundant was generally not avail- 
able. On many machines, it still isn’t. Where such a compiler is not available, a 
good programmer can occasionally achieve significant performance improvements by 
explicit use of register. We see no reason for inlining to be considered radically 
different. In fact, inlining could be a nastier problem for a compiler than register 
allocation because good inlining in the absence of the source text of the function to 
be inlined can be very difficult. Also, without a mechanism like inline for expli- 
citly making the source text available to the compiler, the source text of the key 
functions — the smallest and most frequently used functions from standard libraries — 
will typically not be available to the compiler. O 


A function (§5.2.2, §8.2.5) defined within the declaration of a class is inline by 
default. 

An inline member function must have exactly the same definition in every com- 
pilation in which it appears. 


m The intent of this rule is to prevent inlining from being a legitimate way of proli- 
ferating definitions of what appears to be a single member function. A compiler that 
relies exclusively on completely separate compilation cannot catch such errors; com- 
pilation systems relying on information stored between compilations can. 

Since this manual does not define the way programs are stored, the definition of 
“exactly the same” is nontrivial and the enforcement of this constraint is often diffi- 
cult; see also §10.8. O 


A class member function need not be explicitly declared inline in the class 
declaration to be inline. When no inline specifier is used, linkage will be exter- 
nal unless an inline definition appears before the first call. 
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class X { 

public: 
int f(); 
inline int g(); // X::g() has internal linkage 
int h(); 

}; 


void k(X* p) 

{ 
int i = p->f£(); // now X::f() has external linkage 
int j = p->g(); 


TS Sore ers 
} 
inline int X::f() // error: called before defined 
// as inline 
{ 
1 A oars 


} 


inline int X::g() 


{ 
hes 
) 
inline int X::h() // now X::h() has internal linkage 
{ 
RE ee 
} 


m These rules were formed to serve the needs of people defining classes. There was 
a strong wish to be able to specify that small, heavily used member functions be 
expanded inline, as well as insistence that the inline specification itself is an 
implementation detail which does not belong in the necessarily class declaration. 

Because C+ is typically compiled by a one pass compiler there is the problem of 
what to do if a function is first declared, then called, and finally defined as an inline. 
Four choices were feasible. 

[1] Require inline in the declaration. 

[2] Disallow declaring a member function inline after calling it. 

[3] Decide that the function has external linkage at the call point. 

[4] Don't decide about linkage until the end of the compilation. 
Option [2] was chosen because code like this was deemed harmless and essential: 


class X { 
public: 
int f(); 
int g(); 
}; 


Section 7.1.2 Function Specifiers 105 


int h(X* p) { return p->f(); } // call X::£() 
// no call of X::g() 


inline int X::f() // error: defined inline 
// after being called 
{ 
TS ee 
) 


inline int X::g() // ok 
{ 

LE oc 
} 


Option [3] would imply that a definition of the function with external linkage is laid 
down when the definition is seen, even though it is inline. This would not be 
convenient because sequences of a declaration without an inline specifier, fol- 
lowed by a call, followed by a definition with an inline specifier occur commonly 
in classes appearing in header files, which may typically be included in several 
separate compilations. The result would be frequent linkage clashes of function 
definitions. Option [4] was deemed to require too many postponed decisions to 
accommodate one pass compilation. 

Note that an inline function is required to have exactly one definition. It is 
therefore illegal to define an inline function with different inline versions in separate 
compilations (§3.3). 

There is no equivalent special rule for nonmember functions. For example, 


extern f(); 
inlinas f OCs tlw eh // error 


is an error because inline implies static and 


extern f(); 
statici TOU CLAE sanae] // error 


is an error (§7.1.1). oO 


The virtual specifier may be used only in declarations of nonstatic class 
member functions within a class declaration; see §10.2. 


7.1.3 The typedef Specifier 


Declarations containing the decl-specifier typedef declare identifiers that can be 
used later for naming fundamental or derived types. The typedef specifier may 
not be used in a function-definition (§8.3). 


typedef-name: 
identifier 


Within the scope (§3.2) of a typedef declaration, each identifier appearing as 
part of any declarator therein becomes syntactically equivalent to a keyword and 
names the type associated with the identifier in the way described in §8. A 


+ ek hp AR 
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typedef-name is thus a synonym for another type. A typedef-name does not intro- 
duce a new type the way a class declaration (§9.1) does. For example, after 


typedef int MILES, *KLICKSP; 
the constructions 


MILES distance; 
extern KLICKSP metricp; 


are all legal declarations; the type of distance is int; that of metricp is 
“‘pointer to int.” 

A typedef may be used to redefine a name to refer to the type to which it 
already refers — even in the scope where the type was originally declared. For 
example, 


typedef struct s { /* sma */.) S; 
typedef int I; 

typedef int I; 

typedef I I; 


m A name introduced by a typedef occupies the same name space as other identif- 
iers (except statement labels — see §6.1) and (except for allowing multiple defini- 
tions as described above) obeys the usual scope rules. Thus, for example, 


typedef long I; 


long I; // error: I redefined 
void f() 
{ 
int I; // ok: hides the type name ‘I’ 


} 


D 


An unnamed class defined in a typedef gets its typedef name as its name. For 
example, 


typedef struct { /* ... */ } S; // the struct is named S 


m This ensures that the struct has a name that can be used for linkage. This style of 
declaration is common in C programs where the name of a structure cannot be used 
as a type name except when prefixed by the keyword struct. Allowing it in CH 
avoids a compatibility problem. 

A cleaner CH alternative is 


StructeSale/se cestode 


o 


A typedef may not redefine a name of a type declared in the same scope to 
refer to a different type. For example, 


| 
| 
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class complex { /* ... */ }; 
typedef int complex; // error: redefinition 


Similarly, a class may not be declared with the name of a type declared in the same 
scope to refer to a different type. For example, 


typedef int complex; 
class complex { /* ... */ }; // error: redefinition 


A typedef-name that names a class is a class-name (§9.1). The synonym may 
not be used after a class, struct, or union prefix and not in the names for 
constructors and destructors within the class declaration itself. For example, 


struct S { 
S(); 
~S()7 
}; 


typedef struct S T; 


Sa=T(); // ok 
struct T * p; // error 


m Consider also, 


struct S; 
typedef struct S T; 
struct: Tò /* aca M Fe A error 
struct S f 
S(); 
Ti); // member function: warn 
-T()7 // error 
~S()7 // ok 
F: 
SELO 77 aca A // ok 


@ Similarly, a npedef-name that names an enumeration may not be used after the 
enum prefix. 

Note that a type name, declared in a typedef or class declaration, may be 
combined with the const and volatile specifiers in another declaration; it may 
not be combined with another type name. Thus given 


typedef int I; 
the following are legal: 


const I ci = 12; //. ci is const int 
volatile I vi; // vi is volatile int 
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but these are not accepted: 


short I shi; // error: can’t combine type specifiers 
unsigned I ui; // error: can’t combine type specifiers 


m The typedef specifier may not be used for a function-definition but it may be 
used in a function declaration (_dcl.fet.del_). For example, 


typedef int (*PF) (char*); 
typedef void* F(unsigned); 


PF pfl; // int (*pf1) (char*) 

F* pf2; // void* (*pf2) (unsigned) 
PLES // void* f(unsigned) 

EER MN ite racers AP. ty // syntax error 


7.1.4 The template Specifier 


The template specifier is used to specify families of types or functions; see $14. 


7.1.5 The friend Specifier 


The friend specifier is used to specify access to class members; see §11.4. 


7.1.6 Type Specifiers 
The type-specifiers are 


type-specifier: 
simple-type-name 
class-specifier 
enum-specifier 
elaborated-type-specifier 
>: class-name 
const 
volatile 


The words const and volatile may be added to any legal nype-specifier in the 
declaration of an object. Otherwise, at most one fype-specifier may be given in a 
declaration. A const object may be initialized, but its value may not be changed 
thereafter. Unless explicitly declared extern, a const object does not have 
external linkage and must be initialized (§8.4; §12.1). An integer const initial- 
ized by a constant expression may be used in constant expressions (§5.19). Each 
element of a const array is const and each nonfunction, nonstatic member of a 
const class object is const (§9,3.1). 


Geen. 
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m Adding const to a declaration ensures that an object to which the const is 
applied cannot have its value changed through an expression involving the name 
being declared unless an explicit type conversion is used to remove the ‘‘constness"’ 
~ and possibly even not then. It is worth remembering, however, that there may be -~ 
other ways of referring to the object and that explicit type casting is possible; 
const does not simply mean ‘store in readonly memory’’ nor does it mean 
“compile-time constant.” 
Fundamentally, saying const obliges and enables the compiler to prevent 
accidental updates of the value of an object using a specific name. For example, 


int. i = J; 
const int* p = éi; // ‘i’ cannot be updated through ‘p’ 
void ff) 
í 
itt; // ok 
} 


Consider also, 


void g() 
í 

(*(int*)p)++; // ok 
} 


Casting away const is generally ill advised since it violates a guarantee making a 
program much harder to understand and debug. It can also be hazardous. This vari- 
ant, for example, may fail: 


const int i = 1; 
const int* p = éi; // ‘i’ cannot be updated through ‘p’ 


void h() 
{ 

(*(int*)p) ++; // may be ok, may be run-time error 
} 


since i might have been put in readonly memory. O 


A const object of a type that does not have a constructor or a destructor may be 
placed in readonly memory. The effect of any write operation on any part of such 
an object is undefined. 


m This implies that most const objects of C+ style class types may not be placed 
in readonly memory, whereas most const objects of built-in types and C style 
structures may. The purpose of this distinction is to allow the use of readonly 
memory for large tables, while still enabling ‘‘constness'’ for class objects to be 
defined by the programmer through the definition of const member functions 
(§9.3). 

Note that since in most practical machine architectures memory cannot be made 
“‘readonly"* during program execution, an object can be placed in readonly memory 
only if it is initialized by a value that can be determined at compile time. For exam- 
ple, 
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const one = 1; // can go in readonly memory 


ffint i) 

{ 
const two = i; // cannot go in readonly memory 
I 


D 


m In CH, the default linkage of a const object is intemal. In ANSI C, the default 
Storage class of a const object is extern. Naturally, explicitly declaring a 
const object extern will provide behavior equivalent to ANSI C, as in the fol- 
lowing: 


extern const MIN = -1; 


Also, CH requires a const object to be explicitly initialized; ANSI C does not. 
The significance of these differences is that CH declarations such as 


const pi = 22/7; 


can appear in header files that are included in many compilations and that in C+ 
consts of suitable types can appear in constant expressions. 


const tblsize = 256; 
short gtbl{tblsize]); 


This implies that simple consts such as 
const int MIN = -1; 
can be used as an alternative to the more traditional C 
#define MIN -1 
and 
enum { MIN = -1 }; 
o 
There are no implementation-independent semantics for volatile objects; 
volatile is a hint to the compiler to avoid aggressive optimization involving the 
object because the value of the object may be changed by means undetectable by a 


compiler. Each element of a volatile array is volatile and each nonfunc- 
tion, nonstatic member of a volatile class object is volatile (§9.3.1). 


m Objects that are accessed by code involved in concurrent activities are obvious 
candidates for being declared volatile. For example, 

— an object accessible to a signal handler, 

— an object used for memory mapped I/O. 
For example, an aggressive optimizer might consider optimizing this: 


char c = ireg[3].data; // skip character 
c = ireg[3].data; 
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into this: 
char c = ireg[3].data; 


on noticing that the same object was assigned from the same location twice without 
using the assigned value. 

Unless the programmer tells the compiler, there really is no way for it to know 
that ireg is a device register and that its member data is ‘‘magically"’ refilled 
with a new value each time it is read. A declaration 


class ioregister | 
AE. teers 
volatile int data; 
Ebi wei 

l; 


ioregister ireg{16]; 


will give the compiler the information it needs to avoid being too clever. O 
If the type-specifier is missing from a declaration, it is taken to be int. 


m As mentioned in §7.1 this can lead to confusion. O 


simple-type-name: 
complete-class-name 
qualified-rypedef-name 
char 
short 
int 
long 
signed 
unsigned 
float 
double 
void 


At most one of the words long or short may be specified together with int. 
Either may appear alone, in which case int is understood. The word long may 
appear together with double. At most one of the words signed and unsigned 
may be specified together with char, short, int, or long. Either may appear 
alone, in which case int is understood. The signed specifier forces char 
objects and bit-fields to be signed; it is redundant with other integral types. 
class-specifiers and enum-specifiers are discussed in §9 and §7.2, respectively. 


elaborated-type-specifier: 
class-key class-name 
class-key identifier 
enum enum-name 
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class-key: 
class 
struct 
union 


If an identifier is specified, the elaborated-type-specifier declares it to be a 
class-name; see §9.1. 

If defined, a name declared using the union specifier must be defined as a 
union. If defined, a name declared using the class specifier must be defined 
using the class or struct specifier. If defined, a name declared using the 
struct specifier must be defined using the class or struct specifier. 


m Requiring consistency in the use of class and struct is pointless and could 
even lead to confusion since they can be used to define completely equivalent 
classes. For example, 


class S$ f 
int i; 
public: 
void f(); 
}; 


can be replaced by 


struct S { 
private: 

int i; 
public: 

void f(); 
); 


without any effect whatsoever. O 


Names of nested types (§9.7) can be qualified by the name of their enclosing class: 


qualified-type-name: 
typedef-name 
class-name :: qualified-type-name 


complete-class-name: 
qualified-class-name 
:: qualified-class-name 


qualified-class-name: 
class-name 
class-name :: qualified-class-name 


A name qualified by a class-name must be a type defined in that class or in a base 
class of that class. As usual, a name declared in a derived class hides members of 
that name declared in base classes; see §3.2. 
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7.2 Enumeration Declarations 


An enumeration is a distinct integral type (§3.6.1) with named constants. Its name 
becomes an enum-name, that is, a reserved word within its scope. 


enum-name: 
identifier 


enum-specifier: 
enum identifier, { enum-list,, } 


enum-list: 
enumerator 
enum-list , enumerator 


enumerator: 
identifier 
identifier = constant-expression 


The identifiers in an enwm-list are declared as constants, and may appear wherever 
constants are required. If no enumerators with = appear, then the values of the 
corresponding constants begin at zero and increase by one as the declaration is read 
from left to right. An enumerator with = gives the associated identifier the value 
indicated; subsequent identifiers without initializers continue the progression from 
the assigned value. The value of an enumerator must be an int or a value that 
can be promoted to int by integral promotion (§4.1). 

The names of enumerators must be distinct from those of ordinary variables and 
other enumerators in the same scope. 


m For example, 


enum color { red, orange, yellow, green, blue ); 


enum fruit { 
apple, 
pear, 
orange, // error: ‘orange’ redefined 
kiwi 
}; 


enum bird { 


emu, 
dodo, 
ostrich, 
kiwi // error: ‘kiwi’ redefined 
// (even though fruit::kiwi == bird::kiwi) 
Me 
int emu; // error: ‘emu’ redefined 








114 Declarations Chapter 7 


The values of the enumerators need not be distinct. An enumerator is considered 
defined immediately after it and its initializer, if any, has been seen. For example, 


enum { a, b, c=0 }; 
enum { d, e, f=e+2 }; 


defines a, c, and d to be 0, b and e to be 1, and f to be 3. 

Each enumeration defines an integral type that is different from all other 
integral types. The type of an enumerator is its enumeration. The value of an 
enumerator or an object of an enumeration type is converted to an integer by 
integral promotion (§4.1). For example, 


enum color ( red, yellow, green=20, blue }; 
color col = red; 

color* cp = &col; 

if (*cp == blue) // 


makes color an integral type describing various colors, and then declares col as 
an object of that type, and cp as a pointer to an object of that type. The possible 
values of an object of type color are red, yellow, green, blue; these values 
can be converted to the int values 0, 1, 20, and 21. Since enumerations are dis- 
tinct types, objects of type color may be assigned only values of type color. 
For example, 


color c = l; // error: type mismatch, 
// no conversion from int to color 


int i = yellow; // ok: yellow converted to int value 1 
// integral promotion 


See also §18.3. 


m Naturally, one can explicitly cast to an enumeration. There is no guarantee, how- 
ever, that the resulting value will be one of the enumerators and the value stored can 
be implementation dependent. For example, 


color c2 = color(i); // explicitly cast int ‘i’ to color 
color c3 = color(600); 
i = c3; 


The value of i after the assignment need not be 600. If color is represented as a 
single byte, which is not unlikely, the value of i will be quite different. 

Appearances to the contrary, there are no operations (except assignment) defined 
on enumerations; variables and constants of enumeration types are converted into 
integers before arithmetic is done. For example, 
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enum bit { one=1, two=2, four=4, eight=8 }; 


void f(bit bl, bit b2) 
í 


bit aa = bl/b2; // error: cannot convert int into bit 
bit bb = bit+b2; // error: cannot convert int into bit 
bit cc = b1; 

ccett; // error: cannot convert int into bit 


) 


The reason arithmetic and logical operations are not defined for enumerations is that 
the results of such operations often are not among the values defined for the 
enumerators. For example, in the call f (two, four), b1/b2 and b1+b2 both get 
the int value 6 and the enumeration bit has no such value. Similarly, cc++ 
causes 1 to be added to the integer value of b1 — in this case 2 — yielding the 


integer value 3. Fortunately, an integer cannot be assigned back into cc without an 
explicit cast. O 


Enumerators defined in a class (§9) are in the scope of that class and can be 
referred to outside member functions of that class only by explicit qualification 
with the class name (§5.1). The name of the enumeration itself is also local to the 
class (§9.7). For example, 


class X { 
public: 
enum direction { left=’l', right=’r’ }; 
int f(int i) 
( return i==left ? 0 : i==right ? 1: 2; } 
}; 


void g(X* p) 


{ 
direction d; // error: ‘direction’ not in scope 
int i; 
i = p->f(left); // error: ‘left’ not in scope 
i = p->f£(X::right); // ok 
Elaes 
} 


7.3 Asm Declarations 


An asm declaration has the form 


asm-declaration: 
asm ( string-literal ) ; 


The meaning of an asm declaration is implementation dependent. Typically it is 
used to pass information through the compiler to an assembler. 
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7.4 Linkage Specifications 


Linkage (§3.3) between CH and non-C# code fragments can be achieved using a 
linkage-specification: 


linkage-specification: 
extern string-literal { declaration-list,,, ) 
extern string-literal declaration 


declaration-list: 
declaration 
declaration-list declaration 


The string-literal indicates the required linkage. The meaning of the string-literal 
is implementation dependent. Linkage to a function written in the C programming 
language, "C", and linkage to a CH function, "C++", must be provided by every 
implementation. Default linkage is "C++". For example, 


complex sqrt (complex); // C++ linkage by default 
extern "C" { 

double sqrt (double); // C linkage 
) 


m Linkage specifications are used both to declare functions and objects defined in 
some other language and to declare C+ functions with linkage that makes them 
usable from other Janguages. For example, 


extern "C" double sgrt (double d) 
{ 

// C++ code 
} 


It might be best to think of a linkage string as indicating a linkage convention rather 
than a language. Different languages may share linkage conventions. O 


Linkage specifications nest. A linkage specification does not establish a scope. 
A linkage-specification may occur only in file scope (§3.2). 


m For example, 


void f() 
{ 
extern "C" double frand(); // error: local linkage 
4/ specification 
Se fuente 
} 


The reason for the restriction was partly to simplify the language rules by not having 
to specify the meaning of multiple linkage specifications in separate scopes. The 
primary reason, however, was that in our experience local declarations like the one 
above were a major source of linkage problems. Far too often, the type specified 
locally was simply wrong. Typically, it had been right when written and on the sys- 
tem for which it was written — then the code was ported or the part of the system it 


fits. 
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referred to changed. Orthogonality and generality did not seem to be sufficient rea- 
sons to extend the language to support a major source of maintenance problems. O 


A linkage-specification for a class applies to nonmember functions and objects 
declared within it. A linkage-specification for a function also applies to functions 
and objects declared within it. A linkage declaration with a string that is unknown 
to the implementation is an error. 

If a function has more than one linkage-specification, they must agree; that is, 
they must specify the same string-literal. A function declaration without a linkage 
specification may not precede the first linkage specification for that function. A 
function may be declared without a linkage specification after an explicit linkage 
specification has been seen; the linkage explicitly specified in the earlier declaration 
is not affected by such a function declaration. 


m Allowing a declaration without a linkage declaration to follow a declaration with a 
linkage specification allows us to localize the linkage specifications in header files 
and to convert programs easily, leaving (redundant) local declarations untouched. 
For example, 


extern "C" double sgrt (double); // from standard header 


// ancient function: 
double myfunction(double argl, double arg2) 
{ 
extern double sqrt (double); 
LT eves 
} 


double sgrt (double d) 

{ 
// spiffy new version of sqrt) 
// written in Ctt 


a 


At most one of a set of overloaded functions (§13) with a particular name can 
have C linkage. See §7.4. 
Linkage can be specified for objects. For example, 


extern "C" { 


Il s 

_iobuf _iob[_NFILE]; 

Iloa 

int _flsbuf (unsigned, _iobuf*); 
// 


} 


Functions and objects may be declared static within the {} of a linkage specifi- 
cation, The linkage directive is ignored for such a function or object. Otherwise, a 
function declared in a linkage specification behaves as if it was explicitly declared 
extern. For example, 
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extern "C" double f(); 
static double f(); // error 


is an error (§7.1.1). An object defined within an 
extern "C" { /* ... */ } 
construct is still defined (and not just declared). 


m This implies that 


extern "C" ('/* 2%. */ } 


can bé used without changing the semantics of the enclosed object definitions, but it 
has the peculiar effect that the declarations 
extern "C" { 
int al; 


} 
extern "C" int a2; 


are not equivalent. Here a1 is defined and a2 only declared. O 


@ Since functions with different linkage may have different calling conventions, a 
linkage specification may have a major effect on pointers to functions. In particular, 
C+ functions that do not have the ellipsis in their argument type may use a more 
efficient calling sequence than has traditionally been used for C functions. For 
example, this defines a function with C linkage taking a pointer to a function with 
C+ linkage as its argument: 


typedef int (*CPPF) (int); 
extern "C" void func(CPPF fp); 


The opposite case, a function with CH linkage taking a function with C linkage as 
its argument can be declared like this: 


extern "C" typedef int (*CF) (int); 
void func(CF fp); 


One could imagine extending the linkage concept to be an integral part of the type 
system, take part in overloading resolution, and so on. Doing so, however, would 
bloat CH compilers with all kinds of features for ‘‘foreign language’’ calls and 
object conversion rules; see §7.1, §7.4. O 


Linkage from CH to objects defined in other languages and to objects defined 
in CH from other languages is implementation and language dependent. Only 
where the object layout strategies of two language implementations are similar 
enough can such linkage be achieved. 

When the name of a programming language is used to name a style of linkage 
in the string-literal in a linkage-specification, it is recommended that the spelling 
be taken from the document defining that language, for example, Ada (not ADA) 
and FORTRAN (not Fortran). 
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m A linkage specification does not affect the semantics of the function or object 
given special linkage; that is, a function given "C” linkage doesn’t suddenly get C 
type checking rules and a variable of type char* given "Pascal" doesn’t sud- 
denly acquire a length field somewhere. The obvious temptation to overload. the 
linkage notation with all kinds of implementation-dependent meaning should almost 
always be resisted in the interest of portability. O 








Commentary 


The following sections discuss how one might use and implement a type-safe 
linkage scheme. 


7.le Linkage Specifications 


As mentioned in §7.4, an implementation must provide linkage to C+ (which is the 
default) and linkage to C. Some implementations will extend the linkage specifica- 
tion mechanism to other languages: Fortran, Ada, Pascal, and so on. The extern 
specifier must be used not only for functions written in other languages to be called 
from a C} program, but also when foreign linkage is to be generated for a C+ 
function that is to be called from another language. For example, 


extern "C" { 
// C++ declarations for C functions to be 
// called from C++ and for C++ functions to 
// be called from C go here 

} 

extern "Ada" { : 
// C++ declarations for Ada functions to be 
// called from C++ and: for C++ functions to 
// be called from Ada go here 

} 


One obvious way of designing foreign linkage would be to build knowledge of 
the types and calling conventions of foreign languages into a CH compiler. For 
example, a CH compiler might convert zero-terminajed C+ strings into Pascal 
strings with a length prefix at the invocation of a function with Pascal linkage and 
use call by reference when calling a function with Fortran linkage, convert a CH- 
object into a roughly equivalent Smalltalk object, and so on. 

There are significant disadvantages to this approach, however. 

— The complexity and speed of a CH compiler would be adversely affected. 

— Two implementations might extend Ch with a linkage specification to the 

same language, say Fortran, in different ways, with the effect that identical 








es fa OAA 
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C+ programs have subtly different behaviors on different implementations. 

— Unless an extension is widely available and accepted, programs that use it 

will not be portable, 

Linkage from CH to another language will usually be best done by a simple 
linkage convention augmented with library routines and rules for argument passing, 
format conversion, and so on. This approach will avoid building knowledge of 
foreign-language-calling conventions into C+ compilers. CH provides facilities 
that ought to make implementing this approach simpler than it would be from most 
other languages. Reference arguments can be used to handle Fortran argument 
passing, for example, and a constructor for a Pascal string type taking a C style 
string can be written easily. 


7.1.l¢c Sharing Header Files with C 


The extern specifier, intended to ease the integration of CH into multilanguage 
systems, allows a programmer to give a set of functions C linkage with only a sin- 
gle linkage specification. This is particularly useful when standard C headers are to 
be used. Given an ANSI C header containing, for example, 


extern double sqrt (double); 
extern double cos (double); 
Ws oe 


one can trivially modify it for use from CH, as follows: 


extern "C" { 


extern double sqrt (double); 
extern double cos (double); 
Veh Re 


} 


Unfortunately, this creates a CH header that cannot be included in a C program. 
Sharing with C can be achieved by conditional compilation (§16). 


ifdef __cplusplus 
extern "C" { 
#endif 


extern double sqrt (double); 
extern double cos (double); 


If see 


#ifdef cplusplus 
} 
fendif 


The macro__ cplusplus is defined by every CH compiler (§16.10). 
If the C header cannot or should not be changed, the extern specification can 


fees 


Section 7.1.1c Sharing Header Files with C 121 


surround the #include, in a separate C+ header file. The CH version of 
math.h might look like this: j 


extern "C" { 
#include <math.h> 
} 


Most C functions used in CH programs come from well-defined C libraries, for 
which there are — or ought to be — header files. Therefore, ideally, linkage specifi- 
cations must be added only to header files. 


7.1.2c Converting C Programs 


Converting C programs and C+ programs from older implementations that didn’t 
provide C linkage specifications to use type-safe linkage yielded two interesting 
observations. The first was that most declarations of C functions scattered in C+ 
programs were either redundant (because the function had already been declared in 
a header file) or at least potentially incorrect (because they differed from their 
corresponding declarations in the header files for some commonly used system). 

The second observation was that introducing linkage specifications revealed 
errors in programs — even in programs that had been considered correct for years. 
The process is reminiscent of running lint on an old C program. Most nontrivial 
programs converted to the new linkage convention contained inconsistent function 
declarations. Many declarations found in programs were simply wrong. That is, 
they differed from the function definitions. This was sometimes caused by sloppi- 
ness, for example, when a programmer declared a function 


EIE; woe 


to quiet the compiler instead of looking up the type of the second argument. A 
more common cause was that a header file had changed since the function declara- 
tion was put in the program so the local declaration didn’t match any more. 

Some programmers try to get around the requirement for explicit C linkage 
specifications by enclosing entire programs in linkage directives. This might be 
considered a reasonable way of converting old CH code with minimal effort if it 
did not require every program that calls a function from such a program to also use 
the C linkage, thereby forfeiting the benefits of argument type checking. Further, 
the limitation that at most one of a set of overloaded functions can have C linkage 
(§7.4) usually defeats this way of converting a program if any of its functions are 
overloaded. 


7.2c Type-safe Linkage 


As C+ is defined, all declarations and all uses of variables, functions, and other 
identifiers must adhere to the type rules. It is not specified how this consistency is 
to be achieved in an environment with separate compilation. 

Ideally, that problem is left for the linker to solve. A linker has access to all 
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the code (in object code form), whereas the compiler has access to only a small 
part of a program at a time. So the obvious solution is to decorate all names emit- 
ted from the compiler to the linker with their types and let the linker do the check- 
ing. 

Unfortunately, linkers are usually rather low-level programs with limited notions 
of type, they differ dramatically from system to system, and they are among the 
hardest programs in a system to change (because everyone depends on them). 

Consequently, C tried to ensure the consistency of separately compiled pro- 
grams by controlling the information given to the compiler in header files. This 
approach works fine up to a point, but does involve extra-linguistic mechanisms, is 
usually error-prone, and can be costly because of the need to have other programs 
(in addition to the linker and the compiler) know about the detailed structure of a 
program. 

Here, we will describe an alternative approach that involves using traditional 
linkers to do type checking by encoding type information in function names. 


7.2.1¢c Function Name Encoding 


He 


Originally designed to implement overloading of functions, name encoding is now 
a common technique for providing type-safe linkage. With function overloading, 
multiple instances of functions with the same name appear in CH source code. 
Naturally, only one instance of a function with any given name can appear in the 
object code, and it must be possible to determine which instance of an overloaded 
function is to be invoked for each call. This can be done by encoding the signature 
of a function (the types of its arguments and of what class, if any, it is a member) 
within the name used in the generated code. This section presents one scheme for 
function name encoding. 

The encoding scheme described here uses both upper- and lower-case charac- 
ters; a slightly different encoding would be needed for implementations that lack 
case distinction in linker names. 

If two CH implementations for the same system use different calling sequences 
or in other ways are not link compatible it would be unwise to use identical encod- 
ings of type signatures. Such implementations might agree on using encodings that 
differ by a single character where incompatibilities exist (only). For example, one 
might use a 'G” in stead of the regular 'F’ to indicate a function. Preserving the 
overall encoding scheme would be valuable to tool builders. 

A function name is encoded by appending its signature to its name. A double 
underscore (__) separates the string representing the function name as it appears in 
the CH source code from the function’s encoded signature, so using names with 
embedded sequences of underscores, like a__b__c, in a CH program is not 
recommended. 

The basic types are encoded as follows: 
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encoding 





void 

char 

short 

int 

long 

float 
double 

long double 


< 
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A global function name is encoded by prefixing the signature with the character 
F. Thus f(int,double,...) becomes f Fide. The function f() is 
equivalent to f (void), soit becomes f__ Fv. 

The name of a class is encoded as the length of the name followed by the name 
itself. An argument of type x, for a class x, will be encoded as 1x and an argu- 
ment of type rec, for a class rec, will be encoded as 3rec. A qualified name 
such as Outer: : Inner is encoded by a 'Q’ (for ‘‘qualified’’) followed by a sin- 
gle digit indicating the number of qualifications followed by the names. Thus 
Outer: : Inner becomes Q250uter5Inner. 


Complex 
bese & 4 


A member function, which is translated to an ordinary function with the object 
for which it is invoked (its this pointer) as an additional first argument (§9.3.1), 
is differentiated from a function whose first argument is of a class type by encoding 
the type of the this pointer before the F. Thus, rec: :update (double) 
becomes update __3recFd and x::f(int) becomes f _1xFi, but 
f(x,int) becomes f _F1xi. 

A constructor for class x taking no arguments, x(), would be encoded as 
_ct__1xFv, and the destructor, ~x (), would be __dt__1xFv. 
Type modifiers are encoded as follows: 














encoding 


7Complex 
Q21X2YY 


simple 
qualified 


modifier 
unsigned 
const 

volatile 
signed 











encoding 





n<aQG 


f (unsigned) becomes f _FUi. If more than one modifier is used, the modifi- 
ers are encoded in alphabetical order, f£(signed const char), which is 
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equivalent to f (const signed char), becomes f _FCSc. 
The type declarators are encoded as follows: 








encoding 


pointer P 
reference R 
array A10 
function F 


pointer to member 


f(char*) becomes f _FPc. The order of declarators and modifiers affects the 
meaning of a declaration (§8), so f (const char* arg) (arg is a pointer to a 
char constant) becomes f __FPCc and f (char* const arg) (arg is a con- 
stant pointer to char) becomes f__FCPc. 

The function return type, as well as the argument types, is encoded for an argu- 
ment that is a pointer to function type. The encoded return type appears after the 
argument types, preceded by a single underscore. For example, f (int 
(*) (char*)) becomes f _FPFPc_1. 

To shorten encodings, repeated types in an argument list need not be repeated in 
full in the name encoding; instead, a reference to the first occurrence of the type in 
the argument list can be used. For example, f (complex, complex) could be 
encoded as f F7complexT1, where T1 is short for ‘‘same type as the first 
argument.’’ Similarly, £ (record, record, record), could be encoded as 
f _F6recordN21, where N21 stands for ‘‘the next two arguments are the same 
type as the first.” 

Function names encoded as described here can be many characters long. Imple- 
mentations that depend on a linker that limits the length of an identifier will have 
to modify this encoding scheme. One way to shorten function names would be to 
store, in the last two characters in the generated name, a hash code representing the 
truncated characters. If a 45-character name is generated on a system with a 31- 
character limit, for example, the last 16 characters can be replaced by a two- 
character hash code, yielding a 31-character name. 

Naturally, encoding signatures into identifiers of limited length loses informa- 
tion about the argument types. If the lost type information was that which made 
the overloaded functions unique, name collisions will occur. Experience has 
shown, however, that 31 characters is usually enough to produce distinct names in 
real programs. Further, a proper linker will detect and report name clashes caused 
by the hash coding. 

The names of operator functions are encoded like this: 
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operator 






operator 


encoding 










ml 









operator encoding 





() (function call) 


[] (subscripting) __ve 
constructor eck 
destructor Sot 
operator new() __nw 
operator delete () dl 


operator T() __op<signature of T> 


7.2.2¢c Decoding Function Names 


Function name encoding allows object code to have distinct names for functions 
that share the same name in the CH source code and enables type-safe linkage, but 
what happens when the linker detects an error or when the programmer tries to use 
a symbolic debugger? A linker that doesn’t understand the C+ compiler’s name 
encoding scheme will report errors using the names found in the object code; on 
most systems, a debugger written for C can be used on the object code generated 
for a CH program and it will correctly refer to the C+ source code, but it will use 
the encoded names found in the object code. 

CH users will want a linker that reports errors using the function names that 
appear in their source code, as well as a debugger that reverses the encoding on 
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output and accepts names as they appear in the CH source on input. Further, a CH 
implementation should ideally provide a name decoder for debugger writers and 
others who deal directly with object code. 

If no function name decoder is available, programmers may need to understand 
the encoding scheme used by their CH implementation. As an interim measure, a 
filter can be provided for processing linker error messages. This output was pro- 
duced by such a filter: 


C++ symbol mapping: 


PathListHead: :~PathListHead() __dt__12PathListHeadFv 
Path: :operatoré (Pathé) __ad__ 4PathFR4Path 
Path: :first () first_ 4PathFv 

Path: :last () last__4PathFv 

Path: :findpath (String&) findpath 4PathFR6String 
Path: :fullpath () fullpath__4PathFv 


Here, encoded and unencoded names of undefined functions are shown side by 
side to help users of tools that haven’t been converted to understand CH encoded 
names. 


7.3c Limitations 


Types of variables are not encoded in their names, nor are the return types of func- 
tions encoded. This makes it impossible to catch errors like these: 


// file 1: 
extern int a; 
int £() { return att; } 


// file 2: 
float a; 
extern float f(); 


The reason for letting these errors go undetected is that changing the name encod- 
ing scheme so that they would be caught would cause other errors that are caught 
under the current scheme to go undetected. Consider encoding variable types and 
function return types. Using X to designate ‘‘return type" and a slightly modified 
example, we would get 


// file 1: 

int a; Eft Nett 
int f() { return att; } PAA he ih Pel 
// file 2: 

float a; za nE 


float f() { return a=1.0; } // £__FxXf 


Now there are two different objects called a and two different functions, with the 
same argument list, called f. This is not legal CH and it is correctly rejected by 
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current linkers under the name encoding scheme described here. Changing the 
encoding scheme to include encoding of variable types and retum types, however, 
would cause this error to be undetected. 

Handling all inconsistencies — thus making a CH implementation 100% type- 
safe — would require either linker support or a mechanism (an environment) allow- 
ing the compiler access to information from separate compilations. 























Declarators 


A declarator declares a single object, function, or type, within a declaration. The 
syntax for declarators, including pointers, references, pointers to members, 
arrays, functions, and types, is explained, as well as how to initialize a declarator 
in a declaration. 


8 Declarators 


The declarator-list appearing in a declaration is a comma-separated sequence of 
declarators, each of which may have an initializer. 


declarator-list: 
init-declarator 
declarator-list’ , init-declarator 


init-declarator: 
declarator initializer,,, 


The two components of a declaration are the specifiers (decl-specifiers; §7.1) 
and the declarators (declarator-list). The specifiers indicate the fundamental type, 
storage class, or other properties of the objects and functions being declared. The 
declarators specify the names of these objects and functions and (optionally) 
modify the type with operators such as * (pointer to) and () (function returning). 
Initial values can also be specified in a declarator; initializers are discussed in §8.4 
and §12.6. 

Declarators have the syntax 
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declarator: 
dname 
ptr-operator declarator 
declarator ( argument-declaration-list ) cv-qualifier-list,,, 
declarator [ constant-expression 
( declarator ) 


mae 


ptr-operator: 

* cv-qualifier-list,o, 

& cv-qualifier-list,,, 

complete-class-name :: * cv-qualifier-list,,, 
cv-qualifier-list: 

cv-qualifier cv-qualifier-list,., 
cv-qualifier: 

const 

volatile 


dname: 
name 
class-name 
~ class-name 
typedef-name 
qualified-type-name 


A class-name has special meaning in a declaration of the class of that name and 
when qualified by that name using the scope resolution operator : : (§12.1, §12.4). 


8.1 Type Names 


To specify type conversions explicitly, and as an argument of sizeof or new, the 
name of a type must be specified. This is done with a type-name, which is syntac- 
tically a declaration for an object or function of that type that omits the name of the 
object or function. 


type-name: 

type-specifier-list_ abstract-declarator,,,, 
type-specifier-list: 

type-specifier type-specifier-list,., 


abstract-declarator: 
ptr-operator abstract-declarator,,, 
abstract-declarator,, ( argument-declaration-list_) cv-qualifier-listoy 
abstract-declarator,,, [ constant-expression 


( abstract-declarator ) 


ont 3 


It is possible to identify uniquely the location in the abstract-declarator where the 
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identifier would appear if the construction were a declarator in a declaration. The 
named type is then the same as the type of the hypothetical identifier. For exam- 
ple, 


int // int i 

int * // int *pi 

int *[3)} // int *p[3] 

int (*) [3] // int (*p3i) [3] 

int *() // int *£() 

int (*) (double) // int (*pf) (double) 


LAET 


name respectively the types “‘integer,’’ ‘‘pointer to integer, ‘array of 3 pointers 
to integers,’’ ‘‘pointer to array of 3 integers," ‘‘function taking no arguments and 
retuming pointer to integer,’ and ‘‘pointer to function taking a double argument 
and retuming an integer.” 


oo 66 


8.1.1 Ambiguity Resolution 


The ambiguity arising from the similarity between a function-style cast and a 
declaration mentioned in §6.8 can also occur in the context of a declaration. In that 
context, it surfaces as a choice between a function declaration with a redundant set 
of parentheses around an argument name and an object declaration with a function- 
style cast as the initializer. Just as for statements, the resolution is to consider any 
construct that could possibly be a declaration a declaration. A declaration can be 
explicitly disambiguated by a nonfunction-style cast or a = to indicate initialization. 
For example, 


struct § { 
S(int); 
); 


void foo (double a) 
{ 


S x(int(a)); // function declaration 
S y((int)a); // object declaration 
S z = int(a); // object declaration 


8.2 Meaning of Declarators 


A list of declarators appears after a (possibly empty) list of decl-specifiers (§7.1). 
Each declarator contains exactly one dname; it specifies the identifier that is 
declared. Except for the declarations of some special functions ($12.3, §13.4) a 
dname will be a simple identifier. An auto, static, extern, register, 
friend, inline, virtual, or typedef specifier applies directly to each 
dname in a declarator-list; the type of each dname depends on both the decl- 
specifiers ($7.1) and its declarator. 
Thus, a declaration of a particular identifier has the form 
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T D 


where T is a type and D is a declarator. In a declaration where D is an unadomed 
identifier the type of this identifier is T. 
In a declaration where D has the form 


( D1 ) 


the type of D1 is the same as that of D. Parentheses do not alter the type of the 
embedded dname, but they may alter the binding of complex declarators. 


m Declarators are intended to allow expressing many types with only a few syntactic 


elements. 
operator meaning 


* pointer 
tia pointer to member 
& reference 
[] array 
() function 





In addition, each operator may be suffixed by const, volatile, or a combination 
of both. 

The declarator syntax of C — and therefore of CH — is widely recognized as 
being unnecessarily hard to read and write. 

The fundamental problem is that the notation is not linear, but mirrors the 
expression syntax which is based on precedences. For example, ‘‘pointer to a vector 
of 10 pointers to functions taking an int argument and retuming a pointer to a 
char" is easy to say and easy to draw on a blackboard. It is not easy to write or 
even read in CH. The use of typedefs (§7.1.3) is strongly recommended for all non- 
trivial types. For example, 


typedef char* F(int); // F is the type 
// functions taking an int 
// argument and returning 
//a pointer to a char 


typedef F* A[10]; // A is the type array of 10 
// pointers to Fs 


A* p; // p is a pointer of the horribly 


// long type mentioned in the 
// paragraph above 


8.2.1 Pointers 


In a declaration T D where D has the form 
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* cy-qualifier-list,,, D1 


the type of the contained identifier is **... cv-qualifier-list pointer to T. The cv- 
qualifiers apply to the pointer and not to the object pointed to. 
, For example, the declarations 


const ci = 10, *pe = &ci, *const cpe = pc; 
int i, *p, *const cp = &i; 


declare ci, a constant integer; pc, a pointer to a constant integer; cpc, a constant 
pointer to a constant integer; i, an integer; p, a pointer to integer; and cp, a con- 
stant pointer to integer. The value of ci, cpc, and cp cannot be changed after 
initialization. The value of pc can be changed, and so can the object pointed to by 
cp. Examples of legal operations are 


i = Ci; 
*cp = ci; 
pctt; 

pe = cpc; 
pe = p; 


Examples of illegal operations are 


ci = 1; // error 
citt+; // error 
*pc = 2; // error 
cp = &ci; // error 
cpctt; // error 
Pp = pc; // error 


Each is illegal because it would either change the value of an object declared 
const or allow it to be changed through an unqualified pointer later. 

volatile specifiers are handled similarly. 

See also §5.17 and §8.4. 

There can be no pointers to references (§8.2.2) or pointers to bit-fields (§9.6). 


m When a const or volatile type specifier appears in a declaration, it modifies 
the immediately following declarator, or, in the declaration of a const member 
function ($9.3), the function’s this pointer (§9.3.1). Thus 


const char* step(3] = { "left", "right", "hop" ); 


declares an array of pointers to chars that are const. The pointers can be 
changed; the chars pointed to cannot. 


step[2] = "skip"; // ok: changes pointer to const char 
step[2] [1] = ‘i’;  // error: can’t change const char 


Had the intention been to declare an array of const pointers to chars, the follow- 
ing would have been correct: 


char* const step[3] = { "left", "right", "hop" }; 
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Here, the chars pointed to can be changed; the pointers cannot. 


step[2] = "skip"; // error: can’t change const pointer 
step(2][1] = ‘i’; // ok: changes char pointed to 
// by const pointer 


To declare an array of const pointers to const chars, the following would be 
used: 


const char* const step[3] = { "left", “right”, "hop" }; 
Neither the pointers nor the chars to which they point may be changed. 


step[2] = "skip"; // error: can’t change const pointer 
step[2] [1] = ‘i’;  // error: can’t change const char 


8.2.2 References 
In a declaration T D where D has the form 


& cv-qualifier-list,,, D1 


opt 


the type of the contained identifier is ‘*... cv-qualifier-list reference to T.” The 
type voidé is not permitted. 


For example, 


void f(double& a) { a += 3.14; } 
IP ote 
double d = 0; 
f(d); 


declares a to be a reference argument of f so the call f (d) will add 3.14 to d. 


int v[20]; 
// 


inté g(int i) { return vli); } 


declares the function g () to return a reference to an integer so g (3) =7 will assign 
7 to the fourth element of the array v. 


struct link { 
link* next; 


}; 


link* first; 
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void h(link*&é p) // ‘p’ is a reference to pointer 
{ 

p->next = first; 

first = p; 

p = 0; 


void k() 

{ 
link* q = new link; 
h(q); 

} 


declares p to be a reference to a pointer to link so h(q) will leave q with the 
value 0. See also §8.4.3. 

There can be no references to references, no references to bit-fields (§9.6), no 
arrays of references, and no pointers to references. The declaration of a reference 
must contain an initializer (§8.4.3) except when the declaration contains an explicit 
extern specifier (§7.1.1), is a class member (§9.2) declaration within a class 
declaration, or is the declaration of an argument or a return type (§8.2.5); see §3.1. 


8.2.3 Pointers to Members 
In a declaration T D where D has the form 
class-name :: *  cv-qualifier-list,,, D1 


the type of the contained identifier is ‘*... cv-qualifier-list pointer to member of 
class class-name of type T.” 
For example, 


class X [{ 
public: 
void f(int); 
int a; 
); 


int X::* pmi = &X::a; 
void (X::* pmf) (int) = &X::f; 


declares pmi and pmf to be a pointer to a member of X of type int and a pointer 
to a member of X of type void (int), respectively. They can be used like this: 


X obj; 

Ties 

obj.*pmi = 7; // assign 7 to an integer 
// member of obj 

(ob}.*pmf) (7); // call a function member of obj 
// with the argument 7 
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Note that a pointer to member cannot point to a static member of a class (§9.4). 
See also §5.5 and §5.3. 


w See the commentary at the end of this chapter for a discussion of pointers to 
members. O 


8.2.4 Arrays 


In a declaration T D where D has the form 


D1 [constant-expression n) 


then the contained identifier has type ‘‘... array of T.” If the constant-expression 
(§5.19) is present, it must be of integral type and have a value greater than 0. The 
constant expression specifies the number of elements in the array. If the constant 
expression is N, the array has N elements numbered 0 to N-1. 

An array may be constructed from one of the fundamental types (except void), 
from a pointer, from a pointer to member, from a class, from an enumeration, or 
from another array. 

When several ‘‘array of’ specifications are adjacent, a multidimensional array is 
created; the constant expressions that specify the bounds of the arrays may be omit- 
ted only for the first member of the sequence. This elision is useful for function 
arguments of array types, and when the array is external and the definition, which 
allocates storage, is given elsewhere. The first constant-expression may also be 
omitted when the declarator is followed by an initializer-list (§8.4). In this case the 
size is calculated from the number of initial elements supplied (§8.4.1). 

The declaration 


float fa[17), *afp[17); 


declares an array of float numbers and an array of pointers to float numbers. 
The declaration 


static int x3d[3) [5] [7]; 


declares a static three-dimensional array of integers, with rank 3x5x7. In complete 
detail, x3d is an array of three items; each item is an array of five arrays; each of 
the latter arrays is an array of seven integers. Any of the expressions x3d, 
x3d[i], x3d[i) [j], x3d[i] [j] [k] may reasonably appear in an expression. 

When an identifier of array type appears in an expression, except as the operand 
of sizeof or & or used to initialize a reference (§8.4.3), it is converted into a 
pointer to the first member of the array. Because of this conversion, arrays are not 
modifiable lvalues. Except where it has been declared for a class (§13.4.5), the 
subscript operator [] is interpreted in such a way that E1[E2] is identical to 
* ((E1)+(E2)). Because of the conversion rules that apply to +, if E1 is an 
array and E2 an integer, then E1[E2] refers to the E2-th member of E1. There- 
fore, despite its asymmetric appearance, subscripting is a commutative operation. 

A consistent rule is followed for multidimensional arrays. If E is an n- 
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dimensional array of rank ixjx - -+ xk, then E appearing in an expression is con- 
verted to a pointer to an (n—1)-dimensional array with rank jx -+ xk. If the * 
operator, either explicitly or implicitly as a result of subscripting, is applied to this 
pointer, the result is the pointed-to (m—1)-dimensional array, which itself is 
immediately converted into a pointer. 

For example, consider 


int x[3][5]; 


Here x is a 3x5 array of integers. When x appears in an expression, it is converted 
to a pointer to (the first of three) five-membered arrays of integers. In the expres- 
sion x[i], which is equivalent to *(x+i), x is first converted to a pointer as 
described; then x+i is converted to the type of x, which involves multiplying i by 
the length of the object to which the pointer points, namely five integer objects. 
The results are added and indirection applied to yield an array (of five integers), 
which in tum is converted to a pointer to the first of the integers. If there is 
another subscript the same argument applies again; this time the result is an integer. 

It follows from all this that arrays in CH are stored row-wise (last subscript 
varies fastest) and that the first subscript in the declaration helps determine the 
amount of storage consumed by an array but plays no other part in subscript calcu- 
lations. 


@ The C notion of an array — which C+ has adopted without change — is very low- 
level. Together with the pointer concept and the rules for converting an array to a 
pointer it provides a mechanism that closely models the memory and address concept 
of traditional hardware. This concept is simple, general, and potentially maximally 
efficient. 

As a low-level concept, it also suffers the following major limitations: 

[1] An array is of fixed size with its size fixed at compile time. 

[2] An array is one-dimensional; talking about multidimensional arrays in C is 

simply referring to a conventional use of arrays of arrays. 
[3] An aray is not self-describing; that is, given a pointer to an array there is no 
information available to determine the array's size. 

The last property means that passing pointers to arrays is inherently dangerous. 

Suggestions have been made about how to improve the C array concept to make 
it “higher level” by removing any or all of the limitations listed above. They all 
suffer from the flaw that in making the notion of an array “‘higher level, they 
remove some of the low-level properties that make the C array/pointer notion such a 
powerful tool for building higher level abstractions. Rather than repairing the C 
array/pointer concept, one ought to use it to build higher level abstractions, Self- 
describing, range checking arrays or the yet more powerful associative arrays are 
obvious candidates for user-defined types built from arrays (see §14.2). The C+ 
concepts of class, operator overloading, and templates support these notions. O 
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8.2.5 Functions 


In a declaration T D where D has the form 


D1 ( argument-declaration-list ) cy-qualifier-list,,, 


the contained identifier has the type ‘*... cv-qualifier-list 


pt function taking argu- 
ments of type argument-declaration-list and returning T.” 


argument-declaration-list: 
arg-declaration-list,,.. 
arg-declaration-list , 


* + "opt 


arg-declaration-list: 
argument-declaration 
arg-declaration-list , argument-declaration 


argument-declaration: 
decl-specifiers declarator 
decl-specifiers declarator = expression 
decl-specifiers abstract-declarator,,, 
decl-specifiers abstract-declarator,,, = expression 


If the argument-declaration-list terminates with an ellipsis, the number of argu- 
ments is known only to be equal to or greater than the number of argument types 
specified; if it is empty, the function takes no arguments. The argument list 
(void) is equivalent to the empty argument list. Except for this special case 
void may not be an argument type (though types derived from void, such as 
void*, may). Where legal, ‘*, ...™ is synonymous with ‘‘...°'. The stan- 
dard header <stdarg.h> contains a mechanism for accessing arguments passed 


using the ellipsis. See §12.1 for the treatment of array arguments. 


m Declaring f (...) may be useless, however, since there is no established portable 
way of accessing arguments to a function without at least one argument before the 
ellipsis. O 


A single name may be used for several different functions in a single scope; this 
is function overloading (§13). All declarations for a function taking a given set of 
arguments must agree exactly both in the type of the value returned and in the 
number and type of arguments; the presence or absence of the ellipsis is considered 
part of the function type. Argument types that differ only in the use of typedef 
names or unspecified argument array bounds agree exactly. 


m In particular f (int []) and f (int*) are the same function. O 


The return type and the argument types, but not the default arguments (§8.2.6), are 
part of the function type. A cv-qualifier-list can be part of a declaration or defini- 
tion of a nonstatic member function, and of a pointer to a member function; see 
§9.3.1. It is part of the function type. 

Functions cannot retum arrays or functions, although they can return pointers 
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and references to such things. There are no arrays of functions, although there may 
be arrays of pointers to functions. 
Types may not be defined in return or argument types. 


m For example, 


void f(struct S { int a, b; ) arg) // error 
{ 

LAs wat 
} 


The reason to prohibit this is that C relies on name equivalence and since S would 
be in the scope of f () the only legal calls of £() would be from within £ () itself. 
The restriction on return types applies for the same reason. 


enum E { A,B,C ) £() // error 
{ 

Ys ais 
} 


In C, these declarations are legal — if poor style — and potentially usable because 
C relies on structural equivalence in places. O 


The argument-declaration-list is used to check and convert actual arguments in 
calls and to check pointer-to-function and reference-to-function assignments and 
initializations. 


m Since the point of declaration is after the complete declarator (§3.2) some pretty 
weird declarations can be written. 


typedef int I; 


void f() 
{ 
extern I I(I a); // int I(int a); 
int i = I(l); // call the function 


} 


Naturally, this is best avoided, though roughly equivalent examples can occur natur- 
ally when program fragments written separately are combined. 
The definition of point of declaration also ensures that this example is illegal: 


int f(int a = £(0)); // error: call of undeclared 
// function ‘f’ 


0 


An identifier can optionally be provided as an argument name; if present in a 
function declaration, it cannot be used except in default arguments (§8.2.6) since it 
immediately goes out of scope; if present in a function definition (§8.3), it names a 
formal argument. In particular, argument names are also optional in function defin- 
itions and names used for an argument in different declarations and the definition 
of a function need not be the same. 

The declaration 
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ints. 5 
*pi, 
f(), 
*fpi (int), 
(*pif) (const char*, const char*); 


declares an integer i, a pointer pi to an integer, a function f taking no arguments 
and returning an integer, a function fpi taking an integer argument and returning a 
pointer to an integer, and a pointer pif to a function which takes two pointers to 
constant characters and retums an integer. It is especially useful to compare the 
last two. The binding of *fpi (int) is * (fpi(int)), so the declaration sug- 
gests, and the same construction in an expression requires, the calling of a function 
fpi, and then using indirection through the (pointer) result to yield an integer. In 
the declarator (*pif) (const char*, const char*), the extra parentheses 
are necessary to indicate that indirection through a pointer to a function yields a 
function, which is then called. 
The declaration 


fseek (FILE*, long, int); 


declares a function taking three arguments of the specified types. Since no retum 
value type is specified it is taken to be int (87.1.6). The declaration 


printf(const char* ...); 


declares a function that can be called with varying number and types of arguments. 
For example, 


printf ("hello world"); 
printf ("a=%d b=%d", a, b); 


It must always have a value, however, that can be converted to a const char* as 
its first argument. 


m Argument names are optional in function declarations (and in a function definition 
for arguments not used in the function). For example, a declaration for a function 
Pow might appear as 


double pow(double x, double y); 
or as 
double pow(double, double); 


Sometimes it is useful to omit an argument name. A function may have extra 
unused arguments — either to allow for a need envisioned for the future, or because 
the function has changed so that it no longer requires an argument but not all the 
calls have been changed or the header file containing the declaration hasn't been 
changed yet. To prevent inappropriate use, a programmer may leave these unnamed. > 

Altematively, well-chosen names may be used to document unused arguments, as 
in this example: 
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int f(int reserved for future use); 
int g(int no_longer_used); 


Including argument names in function declarations allows for better documenta- 
lion because the documenter can refer to an argument by name, rather than as ‘‘the 
second argument.’ 9 


8.2.6 Default Arguments 


If an expression is specified in an argument declaration this expression is used as a 
default argument. All subsequent arguments must have default arguments supplied 
in this or previous declarations of this function. Default arguments will be used in 
calls where trailing arguments are missing. A default argument cannot be redefined 
by a later declaration (not even to the same value). A declaration may add default 
arguments, however, not given in previous declarations. 

The declaration 


point(int = 3, int = 4); 


declares a function that can be called with zero, one, or two arguments of type 
int. It may be called in any of these ways: 


point(1,2); point(1); point(); 


The last two calls are equivalent to point (1,4) and point (3, 4), respectively. 


@ The point function could equivalently have been declared like this: 


point (int,int); 
point (int, int = 4); 
point (int = 3, int); 


but, not like this: 


point (int,int); 

point ( 
int = 3, // error: default argument not at end 
int 

); 

point(int, int = 4); 


or like this: 


point (int, int); 
point(int, int = 4); 
point ( 
int = 3, 
int = 4 // error: redefinition of default argument 
Ms 


C+ prohibits the obvious call syntax and semantics for calling point () given a 
default value for only the first argument, which would be 
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point (,3); // syntax error 


It was felt that having empty arguments significant was not only too subtle, but also 
seriously decreased the opportunities for detecting errors; an extra comma in an 
argument list is not an unusual result of bad typing or sloppy editing. O 


m One useful way of thinking about default arguments is as a shorthand for defining 
a set of overloaded functions. For example, instead of writing 


point (int = 3, int = 4); 
we might have written 


point (int,int); 
inline point (int a) { return point(a,4); } 
inline point() { return point(3,4); } 


This is a plausible and general way of implementing default arguments. O 


Default argument expressions have their names bound and their types checked 
at the point of declaration, and are evaluated at each point of call. In the following 
example, g will be called with the value f (2): 


int a = 1; 


int f(int); 
int g(int x = f(a)); // default argument: f(::a) 


void h() { 
a= 2; 
{ 
int a = 3; 
g(); L2G ENa) 


} 


Local variables may not be used in default argument expressions. For example, 


void f() 

{ 
intti; 
extern void g(int x = i); // error 
Wh Sac 

} 


Note that default arguments are evaluated before entry into a function and that 
the order of evaluation of function arguments is implementation dependent. Conse- 
quently, formal arguments of a function may not be used in default argument 
expressions. Formal arguments of a function declared before a default argument 
expression are in scope and may hide global and class member names. For exam- 


ple, 


| 
| 
| 
I 
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int a; 
int f{int a, int b 


a); // error: argument ‘a’ 
// used as default argument 
typedef int I; 


int g(int I, int b = I(2)); // error: ‘int’ called 


1i 


Similarly, the declaration of X::mem1 () in the following example is illegal 
because no object is supplied for the nonstatic member X: :a used as an initializer. 


class X { 
int a; 
static b; 
meml (int i 


a); // error: nonstatic member ‘a’ 
// used as default argument 
B); 7/7 ‘ok 


mem2(int i 


}; 


The declaration of X::mem2() is legal, however, since no object is needed to 
access the static member X::b. Classes, objects, and members are described in 


§9. 


m Note that in a declaration of an object or function qualified by a class name 
default arguments are analyzed in the scope defined by the class name. For exam- 


ple, 


int à; 


class Y f 
static int a; 
flint = "aye Ff Ysa 
glint}; 

NaF 


< 


iig(int x = a) 4/ Yiia 


E 0% 


oO 


A default argument is not part of the type of a function. 


int f(int = 0); 
void h() 
{ 
int j = £(1); 
int k = £(); // fine, means £(0) 
} 


int (*pl) (int) = &f; 
int (*p2)() = &f; // error: type mismatch 
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An overloaded operator (§13.4) cannot have default arguments. 


@ Note that the usual scope rules apply to function declarations, so a function 
declaration in an inner scope hides a declaration of the same function in an enclosing 
scope. This implies that one cannot in an inner scope add default arguments to 
default arguments specified in the enclosing scope. 


point(int, int = 4); 
int p2(int = 3); 


void f() 
{ 
extern point ( 
int = 3, // error: default argument not at end 
int 
Mi 
extern int p2(int = 4); // ok 
TP Ea aa 


o 


m Early versions of C+ allowed multiple default initializers for a single argument, as 
long as they were equivalent. Defining ‘‘equivalent’’ proved problematic, however. 
A programmer might reasonably consider the initializers for x here to be equivalent: 


int f(int x = 1+3); 
int f(int x = 2+2); // error: two initializers for x 


Now consider these initializers for y: 


void g(float y 
void g(float y 


1. 333333333); 
4/3); // error: two initializers for y 


i] 


Are they equivalent? 
One might propose that default initializations be considered equivalent if they are 
lexically identical, but doing so would make 


void h(int a = f()); 
different from 

void h(int a = f() + 0); // error: two initializers 
Further, it would require the two declarations 


void j(char* p = "asdf"); 
void j(char* p = "asdf"); // error: two initializers 


to match. This would be difficult to do on implementations where multiple 
occurrences of the same string do not share storage (whether two strings have the 
same address is implementation dependent — §2.5.4). 

Allowing multiple occurrences of equivalent argument initializers would render 
the semantics of the language dependent on the implementation of constant expres- 
sion evaluation. Allowing nontrivial equivalences (especially of expressions whose 
type is not integral) demands complexity in the constant expression evaluator which 


F 
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is not otherwise required by the language. Thus CH no longer allows multiple 
default initializers for an argument. O 


8.3 Function Definitions 


Function definitions have the form 


function-definition: 
decl-specifiers,,,, declarator ctor-initializer,,, fct-body 


fet-body: 
compound-statement 


The declarator in a function-definition must contain a declarator with the form 
D1 ( argument-declaration-list ) cv-qualifier-list,,, 


as described in §8.2.5. 
The formal arguments are in the scope of the outermost block of the fct-body. 
A simple example of a complete function definition is 


int max(int a, int b, int c) 
{ 
int m= (a> b) 7? a = D 
return (m > c) 2? m: c; 


) 


Here int is the dec/-specifiers, max (int a, int b, int c) is the declarator, 
{ /* ... */ } is the fct-body. 

A ctor-initializer is used only in a constructor; see §12.1 and §12.6. 

A cy-qualifier-list can be part of a member function declaration, member func- 
tion definition, or pointer to member function only; see §9.3.1. It is part of the 
function type. 

Note that unused formal arguments need not be named. For example, 


void print(int a, int) 
{ 

printf("a = $d\n",a); 
} 


m This is useful for reserving a space in the argument lists. This way future needs 
can be served without affecting the interface. Leaving the name out clearly states 
that the argument is not intended to be used, thus suppressing helpful compiler wam- 
ings to that effect. O . 


m A function may change the value of its arguments. Such changes propagate back 
to the caller only if the argument is of a non-const reference type. Altematively, a 
function can change values through pointers, For example, 
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void f(int i, int* p, int& r, const inté rc) 


{ 
itt; // increment local copy only 
ptt; // increment local copy of pointer only 
(*p)++; // increment object pointed to 
rtt; // increment actual argument 
rcett; // error: actual argument considered constant 
} 


In early versions of CH where temporaries were allowed as initializers for non- 
const references the increment r++ might have affected only the temporary used 
as the argument and not the actual argument. This was a trap that caused subtle 
errors. Hence the change in the rules; see §8.4.3; 0 


m There is only one guaranteed way of accessing arguments passed using the ... 
mechanism. The standard header file <stdarg.h> as specified for ANSI C will 
provide declarations that can be used by a function that does not know the number 
or types of its arguments when it is compiled. A familiar example of such a func- 
tion is C’s printf. 

The <stdarg.h> header will declare the following: 

— the type va_list used to represent variable argument lists. 

— the macro 


void va_start (va_list ap, lastarg); 


where lastarg is the last named parameter in the variable argument list. 
va_start must be called before the unnamed arguments are accessed; 
invoking va_start initializes ap to point to the first of the unnamed argu- 
ments. 

— the macro 


type va_arg(va_list ap, ype); 


where type is the type of the next argument in the argument list. After 
va_start has been invoked, each invocation of va_arg will yield a value 
of type type from the argument list and will modify ap to point to the next 
argument. 

— the macro or function 


void va_end(va_list ap); 


va_end must be called after the arguments have been accessed and before 
the function retums. 
The following example, which defines a function numprint to print an integer 
or floating point value given a print f-style format specification, shows how 4 
variable-length argument list might be used: 


d 
“4 
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finclude <stdio.h> 
finclude <stdarg.h> 


void numprint(char* format ...) E 


{ 
va_list ap; 


va_start(ap, format); // initialize ap 


for (char* p=format; *p; ptt) { 
if (*p == ‘$") [ 
switch (*++p) { 
case ‘d’: 
int ival=va_arg(ap, int); 
printf("td", ival); 
break; 
case ‘f’: 
double dval=va_arg(ap, double); 
printf ("if", dval); 
break; 
} 
} 
else printf("tc",*p); 
} 


va_end(ap); // must call to clean up 


C+ allows the declaration f (...) even though there is no guaranteed way of 
accessing the actual arguments from within the definition of £(). The intent was to 
provide an equivalent to C’s completely unchecked function call. Don't use it. 

People who are used to programming with implementations of Classic C where 
arguments are passed as a contiguous region of storage will look for ways of passing 
an argument list from a function specified with ... to another without copying or 
determining the number of actual arguments. For example, 


void another _handler(const char*); 


void some_error_handler(const char* format ...) 
f 
Tf wee 
another handler (format); // not portable 
exit (99); 
) 


This is not portable in C or Ch. Some implementations will pass some or all argu- 
ments in registers or special storage thus violating the assumption that arguments are 
passed in a contiguous region of storage. To do this portably, the va_list type 
and the macros from <stdarg.h> must be used. For example, 
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finclude <stdarg.h> 
void real_handler (const char*, va_list); 


void my_error_handler (const char* format ...) 
{ 
hikari 
va_list ap; 
va_start (ap, format); 
real handler (format, ap); // portable 
va_end (ap); 
exit (99); 
} 


Naturally, real_handler() must in tum use the va_arg() macro to read its 
arguments. For example, 


#include <stdarg.h> 


void real_handler {const char* format, va_list ap) 


{ 
// assume that ‘format’ tells us that 
// three arguments, a char*, an int, and a double, 
// are passed - in that order - by the va_list ‘ap’ 
char* p = va_arg(ap, char"); // read a char* 
int i = va_argfap,int); // read an int 
double d = va_arg (ap, double); // read a double 
LT Beats 

} 


The <stdarg.h> facility is a descendent of Andrew Koenig’s <varargs.h> 
facility and its use is very similar. O 


8.4 Initializers 
A declarator may specify an initial value for the identifier being declared. 


initializer: 


assignment-expression 
{ initializer-list opine 
( expression-list ) 


initializer-list: 
expression 
initializer-list. , expression 
{ initializer-list +o, } 


m There are clearly too many notations for initialization, but each seems to serve 4 
particular style of use well. The ={initializer-list, ,,,} notation was inherited from 
C and serves well for the initialization of data structures and arrays, For example, 
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struct Conf { 
char* month; 
int year; 
char* location; 
} ceppi] = { 
"November", 1987, "Santa Fe", 
"October", 1988, "Denver", 
"November", 1989, "Tyngsboro", 
"April", 1990, "San Francisco” 
he 


The =expression notation also comes from C and is most natural for initializing sim- 
ple variables, especially variables of arithmetic or pointer type. For example, 
int i = 1; 


complex z = complex (2.3, 4); 
char* p = "No.4.0p29"; 


The (expression-list) notation for initialization came from Simula and seems best 
when one is creating objects of types that do not fit the arithmetic mold. For exam- 


ple, 


Vector v(100); // vector of 100 integers 
Task ring_monitor("monitor", 1024, SHARED); 


Rewriting the last two sets of examples shows the style difference. 


int i(1); 
complex z(2.3,4); 
char* p("No.4.0p29"); 


Vector v = 100; // vector of 100 integers 
Task ring_monitor = Task ("monitor", 1024, SHARED); 


Semantically there is little difference, but notation does matter and people will differ 
on aesthetics and develop a variety of styles. See also §8.2.4, §12.6. O 


Automatic, register, static, and external variables may be initialized by arbitrary 
expressions involving constants and previously declared variables and functions. 


int f(int); 
int a = 2; 
int b = f(a); 
int c(b); 


A pointer of type const T*, that is, a pointer to constant T, can be initialized 
with a pointer of type T*, but the reverse initialization is illegal. Objects of type T 
can be initialized with objects of type T independently of const and volatile 
modifiers on both the initialized variable and on the initializer. For example, 
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int a; 
const int b = a; 
int c = b; 


const int* p0 = &a; 

const int* pl = &b; 

int* p2 = &b; // error: makes a pointer to 
// nonconst point to a const 


int *const p3 = p2; 
int *const p4 


" 

yel 
H 

` 
ENE 
sȚs 


error: makes a pointer to 
// nonconst point to a const 
const int* p5 = pl; 


The reason for the two errors is the same: had those initializations been allowed 
they would have allowed the value of something declared const to be changed 
through an unqualified pointer. 

Default argument expressions are more restricted; see §8.2.6. 

Initialization of objects of classes with constructors is described in §12.6.1. 
Copying of class objects is described in §12.8. The order of initialization of static 
objects is described in §3.4 and §6.7. 

Variables with storage class ‘static (§3.5) that are not initialized are guaranteed 
to start off as 0 converted to the appropriate type. The initial values of automatic 
and register variables that are not initialized are undefined. 

When an initializer applies to a pointer or an object of arithmetic type, it con- 
sists of a single expression, perhaps in braces. The initial value of the object is 
taken from the expression; the same conversions as for assignment are performed. 

Note that since () is not an initializer, 


X a(); 


is not the declaration of an object of class X, but the declaration of a function tak- 
ing no argument and returning an X. 

An initializer for a static member is in the scope of the member’s class. For 
example, 


int a; 
struct X { 


static int a; 
static int b; 
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m The qualification X:: extems the scope of X for the duration of the declaration. 
This ensures that a means X::a and not ::a. This is exactly what happens when a 
member function is declared outside its class declaration. For example, 


int à; 
class Y { 
int a; 
int £(); 
Me 
int Y::f() { return a; j // return Y::a not ::a 


See §8.2.6 for initializers used as default arguments. 


8.4.1 Aggregates 


An aggregate is an array or an object of a class ($9) with no constructors (§12.1), 
no private or protected members (§11), no base classes (§10), and no virtual func- 
tions ($10.2). When an aggregate is initialized the initializer may be an initializer- 
list consisting of a brace-enclosed, comma-separated list of initializers for the 
members of the aggregate, written in increasing subscript or member order. If the 
aggregate contains subaggregates, this rule applies recursively to the members of 
the subaggregate. If there are fewer initializers in the list than there are members 
of the aggregate, then the aggregate is padded with zeros of the appropriate types. 
For example, 


struct S { int a; char* b; int c; }; 
Sss, = (513) Zasdl 5}; 


initializes ss.a with 1, ss.b with "asdf", and ss.c with 0. 

An aggregate that is a class may also be initialized with an object of its class or 
of a class publicly derived from it (§12.8). 

Braces may be elided as follows. If the initializer-list begins with a left brace, 
then the succeeding comma-separated list of initializers initializes the members of 
the aggregate; it is erroneous for there to be more initializers than members. If, 
however, the initializer-list or a subaggregate does not begin with a left brace, then 
only enough elements from the list are taken to account for the members of the 
aggregate; any remaining members are left to initialize the next member of the 
aggregate of which the current aggregate is a part. 

For example, ` 


intix EARL ees EAN 


declares and initializes x as a one-dimensional array that has three members, since 
no size was specified and there are three initializers. 
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float y(4)[3] = { 
(21537250) 
{G27 4,068); 
EBY An 


is a completely-bracketed initialization: 1, 3, and 5 initialize the first row of the 
array y [0], namely y[0] [0], y[0] [1], and y [0) [2]. Likewise the next two 
lines initialize y[1] and y [2]. The initializer ends early and therefore y [3] is 
initialized with zeros. Precisely the same effect could have been achieved by 


float y[4][3) = { 
abr by ay ede PP SE TS ea | 
E 


The last (rightmost) index varies fastest (§8.2.4). 

The initializer for y begins with a left brace, but the one for y [0] does not, 
therefore three elements from the list are used. Likewise the next three are taken 
successively for y[1] and y [2]. Also, 


float y[4] [3] = { 
SED Net Geeta Yee a GE Po free Be 
}; 


initializes the first column of y (regarded as a two-dimensional array) and leaves 
the rest 0. 


Initialization of arrays of objects of a class with constructors is described in 
§12.6.1. See 
The initializer for a union with no constructor is either a single expression O 


the same type, or a brace-enclosed initializer for the first member of the union. For 
example, 


union u { int a; char* b; }; 
ub =a; 

uc=1; // error 
ud={ 0, "asdf" }; // error 
ue = { "asdf" }; // error 


SEE: ini- 
There may not be more initializers than there are members or elements to in 
tialize. For example, 


char cv[4] = {-‘a!, ‘’s’, ‘'d’, ‘£', 0°); // error 


is an error. 
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8.4.2 Character Arrays l 


A char array (whether signed or unsigned) may be initialized by a string-literal; 
successive characters of the string initialize the members of the array, For exam- 
ple, 


char msg[) = "Syntax error on line s\n"; 


shows a character array whose members are initialized with a string. Note that 
because ’\n’ is a single character and because a trailing ‘\0’ is appended, 
sizeof (msg) is 25. 

There may not be more initializers than there are array elements. For example, 


char cv[4] = "asdf"; // error 
is an error since there is no space for the implied trailing ’ \0’. 


m In this, CH differs from ANSI C, where the example is allowed and is intended to 
be a convenience to the programmer. O 


8.4.3 References 


A variable declared to be a T&, that is “‘reference to type T” (§8.2.2), must be ini- 
tialized by an object of type T or by an object that can be converted into a T. For 
example, 


void f() 
{ 
ines ie 
ints r // ‘xr’ refers to ‘i’ 
r= 1; // the value of ‘i’ becomes 1 
int* p /{ Sp points) toni! 
inté rr = r; // ‘rr’ refers to what ‘r’ refers to, 
// that is, to ‘i’ 


i] 
H- 
` 


1i 
m 
lal 


) 


A reference cannot be changed to refer to another object after initialization. 


m This means that references are not first class citizens in CH. In a very real sense 
a reference is not an object. Sometimes, like r above for example, a reference can 
be optimized out of existence. 

It would be easy to make references into *‘proper objects’’ in C+. This would 
require either that there be two sets of operations on references (one referring to the 
reference itself, the other referring through the reference to whatever it refers) or that 
operators have their meanings subtly dependent on their operands. Simula uses the 
former approach, Algol68 the latter. For C+ the former approach would require at 
least twelve new operators to match & (address of), ++ (prefix and postfix), -— (pre- 
fix and postfix), =, ==, !=, <, >, <=, and >=. The latter approach seemed too sub- 
tle for CH. 

Since C already had pointers that are first class citizens and proper objects, we 
decided to leave CH references without pointer-like operations and let users express 
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things that require pointer-like behavior using a pointer type. 

A consequence of references not being objects is that there can be no arrays of 
references. A declaration of an array of references seems to make sense. For exam- 
ple, 

int a, b; 
int& v[] = a, b; // error: no arrays of references 


Using such an array, however, would be most problematic. Unless several funda- 
mental rules of the language are changed, accessing it would imply the existence of 
Pointers to references. By definition v/1] means *(v+1), and we would have 
thus created a pointer to a reference. O 


Note that initialization of a reference is treated very differently from assignment to 
it. 


@ Initialization is an operator that operates on the reference itself, whereas assign- 
ment — like every other operation — operates through the reference on the object 
referred to. O - 


Argument passing (§5.2.2) and function value return (§6.6.3) are initializations. 


m By far the major use of references in C+ is for passing arguments and for retum- 
ing values. In the former case arguments of some type const Té act as an effi- 
cient alternative to call by value and in the latter case references are used to allow 
function calls on the left side of assignments. O 


The initializer may be omitted for a reference only in an argument declaration 
(§8.2.5), in the declaration of a function retum type, in the declaration of a class 
member within its class declaration (§9.2), and where the extern specifier is 
explicitly used. For example, 


inté rl; // error: initializer missing 
extern inté r2; // ok 


If the initializer for a reference to type T is an lvalue of type T or of a type 
derived (§10) from T for which T is an accessible base (§4.6), the reference will 
refer to the initializer; otherwise, if and only if the reference is to a const an 
object of type T will be created and initialized with the initializer. The reference 
then becomes a name for that object. For example, 


double d = 1.0; 


double& rd = d; // rd refers to ‘d’ 
const double& rcd = d; // rcd refers to ‘d’ 


doubleé& rd2 = 1; // error: type mismatch 
const double& rcd2 = 1; // rcd2 refers to temporary 
// with value ‘1’ 


| 
1 
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m The distinction between references to consts and references to non- consts is a 
major change from earlier definitions of C++. The distinction was made to eliminate 
a major source of errors and surprises. Earlier, all references could be initialized to 
refer to temporary objects so all the initializations above were legal. 

Naturally, this feature will be faded out of implementations slowly, to avoid 
breaking working code. O 


A reference to a volatile T can be initialized with a volatile T or a 
plain T but not a const T. A reference to a const T can be initialized with a 
const T ora plain T or something that can be converted into a plain T but not a 
volatile T. A reference to a plain T can be initialized only with a plain T. 

The lifetime of a temporary object created in this way is the scope in which it is 
created (§3.5). 


B Note that char is a type that differs from both signed char and unsigned 
char, so in 

char c = ‘c’; 

charé rc = c; 


const signed charé rsc = c; 
const unsigned chars ruc = c; 


rsc and ruc will each be initialized to a temporary, even though the representation 
of plain char will be identical to one of the explicit varieties. Had const been 
left out of the declarations of rsc and ruc, both initializations would have been 
errors. The initialization of rc does not require the use of a temporary. 

This rule follows the same logic as the rule for pointers to the different flavors 
of char (§3.6.1). D 


Note that a reference to a class B can be initialized by an object of a class D pro- 
vided B is an accessible and unambiguous base class of D (in that case a D is a B); 
see §4.7, 








Commentary 





8.lc Pointers to Members 


As initially defined, the C++ language provided no way of expressing the concept of 
a pointer to a member of a class ($9.2). When a pointer to a member function 
(§9.3) was needed, in an error handling function for example, users had to subvert 
the language’s type checking. 

The type of a nonmember function, int f£(char*), for example, is int 
(char*), and a pointer to such a function is of type int (*) (char*). 
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Pointers to nonmember functions con be declared and used like this: 
void f(char*); // declare function 
f£("Hello!"); // call 
void (*pf) (char*); // declare pointer to function 


(*pf) ("Goodbye!"); // call through pointer 


Consider a trivial class for which the member function £ and object i are 
declared, and an object s of that class, declared as follows: 


Struct S f 
int f(char+*); 


ant Ar 
l; 
TERS eE (Chara) © Ct oe SA) 
Sass 


One can take the address of the member i in the object s, as follows: 
int* ip = &s.i; // ip points to s's member i 


The notation for pointer to member of class S is S: : * (§8.2.3) and the notation for 
taking the address of a member of a class S is &S::. Thus one can take the 
address of a member i in class S as follows: 


ANG Ss ALSIP ES vi; // sip gets offset of ‘i’ in an S$ 


Note that &s.i yields the address of i in the specific object s, whereas &S: 71 
yields a representation of i's relative position in all objects of class S (§5.3). 


It is not legal to take the address of a member that doesn’t have a name. For 
example, 


class X { public: int a[2]; }; 
int X::*ai = &X::a[1]; // error: can’t take address 
// of unnamed member 


In a definition the member function £ of class S declared above appears as 
int S::f(char*) { /* ... */ } 
The type of S: :f is now expressed as int S::(char*). That is, ‘‘member of 


S that is a function taking a char* argument and retuming an int.” A pointer 
to such a function is of type int (S::*) (char*). One can now write 
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// declare and initialize pointer to member function 
int (S::*pmf) (char*) = &S::f; 


S s var; 
// call function through pointer for the object s var 
int j = (s_var.*pmf) ("hello"); 


The syntax isn’t the most readable one can imagine. It is, however, consistent with 
the C declarator syntax. 

A pointer to member function can be called through a pointer to an object, as 
follows: 


S* p; 
// call function through pointer for the object *p 
int k = (p->*pmf) ("goodbye"); 


A virtual function ($10.2) can be called through a pointer to an object. Con- 
sider the following code: 


struct B { 
virtual vf(); 


int £2(B* pb, int (B::*pbf) ()) 

{ 
// call virtual function pointed to 
// by pbf for object that pb points to 
return (pb->*pbf) (); 


void funcl () 


{ 
Dd; 


// call f2 and pass pointer to derived object 
// and pointer to virtual function in base class 
int i = f2(&d, &B::vf); 

} 


In £2, as called by £1 shown here, D::vf£() will be invoked. Naturally, the 
implementation looks in d's table of virtual functions exactly as it would for a call 
to a virtual function identified by name rather than by a pointer. 
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8.1.le Pointers to Static Members 


Pointers to static members are ordinary pointers (§3.6.2). Thus the pointer to 
member syntax is not used with static members. The address of a static member is 
taken with the pointer syntax for nonmember objects. Similarly, a pointer that 
points to a static member is dereferenced as an ordinary pointer. 


8.1.2c Implementation of Pointers to Members 


Pointers to members must be implemented in a way that is consistent with the lay- 
out of class objects and the implementation of inheritance. In particular, since it is 
possible to have a pointer to a virtual function, the implementation of pointers to 
members depends on the way virtual base classes are represented and on the way 
virtual function call is implemented. The explanation below assumes the object and 
virtual table layout described in §10.2 and §10.10. 

This implies that pointers to members are implemented as structures holding 
relative positions in objects and indexes into virtual function tables. Thus, examin- 
ing the value of a pointer to a member will not necessarily reveal a machine 
address. It is recommended that the reader understand the implementation of multi- 
ple inheritance with virtual base classes and virtual functions before reading this 
section (see §10.2, $10.3, §10.5, §10.6, §10.7, §10.8, and §10.10). 

The simplest implementation of a pointer to a nonstatic data member is simply 
the offset of the member in an object of the class type (the layout of class objects 
is described in §10.2). Consider 


class X { 
public: 
int meml; 
int mem2; 
); 


int X::*pm = &X::mem2; 


If class X is laid out in memory such that mem2 is offset four bytes from the start 
of an X object, then the value stored in pm could be 4. To allow the representation 
of a null pointer to member to be 0, however, a better choice is 5; that is, the 
offset plus 1. 

Implementation of pointers to nonstatic member functions is more complicated 
since more information needs to be retained to call through the pointer successfully. 
A pointer to a nonstatic, nonvirtual function member must contain the following: 

— the offset, delta, of the this pointer appropriate for the class (possibly a 

base class) for which the function is defined (§10.2, §10.3), and 

— the address of the function. 

A pointer to a nonstatic virtual function must contain 
— the offset of the this pointer, 
— the offset of the pointer vptr( to the class's virtual function table vtbl( 
(§10.7, §10.8), and 
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— the index of the function in the virtual function table. 
Pointers to nonstatic member functions can be implemented as follows: 


typedef int (*vptr) (); 


class Ptr_to_mem_func { 
public: 
short delta; // offset of ‘this’ pointer 
short index; // index into vtbl 
vptr faddr; // address of nonvirtual function 
short v off; // offset of vptr 
}; 


Note that the logical implementation for the virtual function table is an array of 
pointer to member functions. 

Because a pointer to member function can point to either a virtual or a nonvir- 
tual function, its implementation needs either the address of the nonvirtual function 
or the offset of the ptr, but not both. Thus the layout of Ptr_to_mem_func 
can be optimized as follows: 


class Ptr_to_mem_func { 


public: 
short delta; // offset of ‘this’ pointer 
short index; // index into vtbl 
union { 
vptr faddr; // for nonvirtual function 
short v_off; // for virtual function 
}; 
Me 


An index can never be negative, so the index field is used to determine whether 
the object is a pointer to a virtual or a nonvirtual member function. If index has 
a negative value, the object is a pointer to a nonvirtual member function and the 
faddr field contains the address of the function. If index has a positive value, 
the object is a pointer to a virtual member function and the v_off field contains 
the offset of the vptr in the class for which the function pointed to is defined. 


Consider 


class Bl { 
InCaLS 
public: 


int Blf(); 
int virtual Blvfl1(); 
int virtual Blvf2(); 
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class B2 { 

aint i; jy Ke 
public: 

int B2f(); 

int virtual B2vf1(); 
}e 


Class D : public Bl, public B2 { }; 


int (D::*pmf1)() = &D::B1f; 
int (D::*pmf2) () = &D::B2f; 
int (D::*pmf3) () = &D::Blvf2; 
int (D::*pmf4)() = 6D::B2vf1; 


If base and derived classes are laid out as described in §10, then the pointers to 
member functions will be declared and initialized to the equivalent of the follow- 
ing: 


Ptr_to mem_func pmfl = 


{ 
0, // Bl is the first base class 
=1, // indicates a nonvirtual function 
&B1::B1f // address of function 

Me 


Ptr_to_mem_func pmf2 = 


{ 
8, // offset of B2 part of a D object 
-l, // indicates a nonvirtual function 
&B2::B2f // address of function 

}; 


Ptr to mem func pmf3 = 


{ 
0, // Bl is the first base class 
2, // index of Blvf2 in Bl’s vtbl 
4 // offset of B1’s vptr 

); 


Ptr to mem_func pmf4 = 


{ 
8, // offset of B2 part of a D object 
1; // index of B2vfl in B2’s vtbl 
12 // offset of B2’s vptr 


Section 8.1,2c Implementation of Pointers to Members 


Naturally, the declaration 
int (D::*pmf0)() = 0; 
produces the equivalent to the following initialization: 


Ptr_to_mem_func pmf0 = {0, 0, 0}; 
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Classes 


A class is a user-defined type. A class declaration specifies the representation of 
objects of the class and the set of operations that can be applied to such objects. 
This chapter presents the syntax and semantics for simple classes. 


The definition of both static and non-static members is discussed, and the 
scope rules involving classes and functions — including local and nested classes 
containing member functions — are described. The mechanisms for controlling 
the layout of class objects, for conforming to externally imposed formats, and for 
maintaining compatibility with C layouts (structs, unions and bit-fields) are 
presented. 


The commentary at the end of this chapter discusses C++'s facilities for express- 
ing interfaces and how design decisions in this area affect compile-time, run- 
time, and space efficiencies. Derived classes (that is, inheritance), access con- 
trol, and special member functions are discussed in the next three chapters. 


9 Classes 


A class is a type. Its name becomes a class-name (§9.1), that is, a reserved word 
within its scope. 


class-name: 
identifier 


Class-specifiers and elaborated-type-specifiers (§7.1.6) are used to make class- 
names. An object of a class consists of a (possibly empty) sequence of members. 


class-specifier: 
class-head { member-list,,, } 





164 Classes Chapter 9 


class-head: 
class-key identifier op, base-speCop, 
class-key class-name base-speCoy, 


class-key: 
class 
struct 
union 


The name of a class can be used as a class-name even within the member-list of 
the class specifier itself. 


m For example, 


class link { link* next; ); 


Note that classes may be unnamed. An unnamed class cannot have constructors 
(§12.1) or destructors (§12.4) and cannot be passed as an argument or retumed as a 
value (since it does not have a name that would allow a matching formal argument 
or a retum value to be declared), O 


A class-specifier is commonly referred to as a class declaration. A class is con- 
sidered defined when its class-specifier has been seen even though its member 
functions are in general not yet defined. 


m@ Except for historical reasons, a class declaration would have been called a class 
definition. 0 


Objects of an empty class have a nonzero size. 


m This implies that objects of an empty class can be allocated and have distinct 
addresses. For example, 


class empty {); // class with no members 


empty el, e2; 
empty* pl = éel; 


void f() 
{ 

if (pl == &e2) error("impossible"); 
} 


Empty classes can be used as place holders during program development. In particu- 
lar, an empty class is sometimes used as a base class (§10) where the programmer 
Suspects that two classes have something in common, but hasn’t yet determined 
exactly what. O 


m Nameless classes can be used (only) to declare singleton objects. For example, 
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struct ( 
Pe spt 
} global; 


Such objects cannot be passed as arguments except by suppressing type checking 
using the ellipsis (§8.2.5). A nameless class cannot have a constructor (§12.1) or a 
destructor (§12.4). Typically, if a class is useful it represents some concept and 
since that will have a name it would be only natural to name the class. A major use 
of the unnamed class syntax is the C construct 


typedef struct { /* ... */ ) mystruct; 
that is equivalent to the CH construct 
struct mystruct { /* ... */ J+ 


o 


Class objects may be assigned, passed as arguments to functions, and retumed 
by functions (except objects of classes for which copying has been restricted; see 
§12.8). Other plausible operators, such as equality comparison, can be defined by 
the user; see §13.4. 


m ‘‘Class’’ is the key concept of Ch. A class is a user-defined type. The class is 
the unit of data hiding and encapsulation (§11.1). The class is the mechanism sup- 
porting data abstraction by allowing representation details to be hidden and accessed 
exclusively through a set of operations defined as part of the class (§9.3, §11.4). 
Polymorphism is supported through classes with virtual functions (§10.2). The class 
provides a unit of modularity. In particular, a class with only static members (§9.4) 
provides a facility akin to what is called a *‘module’’ in many languages: a named 
collection of objects and functions in their own name space. O 


A structure is a class declared with the class-key struct; its members and 
base classes (§10) are public by default (§11). A union is a class declared with the 
class-key union; its members are public by default and it holds only one member 
at a time (§9.5). 


m Thus the CH class concept can be seen as a generalization of the C notion of a 
structure or — looking at it the other way — the C concept of a structure is a simple 
variant of the C+ class concept. In particular, C structures do not support member 
functions of any kind. Having a C struct be a simple variant of a Ch class 
has important implications for cooperation between C and G+ programs. The layout 
of structures that are both C and C+ is identical, so such structures can be shared 
freely between C and CH programs without space or time overheads caused by 
conversion or translation, Even for classes using features not available to C, the 
correspondence between the Ch class layout and an equivalent C structure layout is 
usually obvious so that sharing can be trivially achieved. See, for example §10.1. O 
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9.1 Class Names 
A class declaration introduces a new type. For example, 


struct: X (C int-a; }; 
struct Y { int a; }; 
X al; 

Y a2; 

int a3; 


declares three variables of three different types. This implies that 


al = a2; // error: Y assigned to X 
al = a3; // error: int assigned to X 


are type mismatches, and that 


ant E(X); 
int: EY); 


declare an overloaded (§13) function £() and not simply a single function f () 
twice. For the same reason, 


struct S { int a; }; 
struct S { int a; }; // error, double definition 


is an error because it defines S twice. 


m In other words, CH relies on name equivalence, not on structural equivalence of 
types. In this it differs from ANSI C — if not from Classic C — that explicitly 
allows a form of structural equivalence between separately compiled program frag- 
ments. g 


A class declaration introduces the class name into the scope where it is declared 
and hides any class, object, function, or other declaration of that name in an enclos- 
ing scope (§3.2). If a class name is declared in a scope where an object, function, 
or enumerator of the same name is also declared the class can be referred to only 
using an elaborated-type-specifier (§7.1.6). For example, 


struct stat { 
// 
}5 


stat gstat; // use plain ‘stat’ to 
// define variable 


int stat(struct stat*); // redefine ‘stat’ as function 


F 
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void f() 
{ 
struct stat* ps; // ‘struct’ prefix needed 
// to name struct stat 
// 
stat (ps); // call stat() 
LY ise 


m This apparently spurious overloading mechanism exists to accommodate programs 
relying on the C notion of separate name spaces for structure names and other 
names. It does so without seriously compromising the C+ notion that the name of a 
class is the name of a type that obeys the usual scope rules and can be used without 
a special prefix (struct, or union, for example) telling the compiler that it is the 
name of a class. O 


m Note that this kind of name overloading can lead to ambiguities. Consider having 
both a constructor and a function of the same name. 


class X { 
LI ere 
X(int}; 
he 


void X(int); 
Any use of X (int) is ambiguous. 
X(1); // error: constructor or global function called? 


Having both a function and a conversion function can cause exactly the same prob- 
lem. 


elass XX fe mee CA Ja 


class YY { 
Yee a 
operator XX(); 
Me 


void XX(YY); 
Any use of XX (YY) is ambiguous. 


YY a; 
XX(a); // error: global function call or 
// conversion of ‘a’ to an XX? 


o 
An elaborated-type-specifier with a class-key used without declaring an object or 


function introduces a class name exactly like a class declaration but without defin- 
ing a class. For example, 
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struct s { int a; }; 


void g() 

' ; 
struct s; // hide global struct ‘s’ 
s* p; // refer to local struct ‘s’ 


struct s { char* p; }; // declare local struct ‘s' 
) 


Such declarations allow declaration of classes that refer to each other. For exam- 
ple, 


class vector; 


class matrix { 
// 


friend vector operator*(matrix&, vector&); 
}; 


class vector { 
// 
friend vector operator* (matrix&, vectors); 


}; 
Declaration of friends is described in §11.4, operator functions in §13.4. If a 


class mentioned as a friend has not been declared its name is entered in the 
same scope as the name of the class containing the friend declaration (§11.4). 


m For example, 


class X { 
friend class Y; // ‘Y’ is in enclosing scope 


}; 
Y* p; // ‘Y’ is in global scope because ‘xX’ is 


D 


An elaborated-type-specifier (§7.1.6) can also be used in the declarations of 
objects and functions. It differs from a class declaration in that if a class of the 
elaborated name is in scope the elaborated name will refer to it. For example, 


struct s (Sinta }; 


void g() 

{ 
struct s* p; // refer to global ‘s' 
p->a = 1; 


} 


A name declaration takes effect immediately after the identifier is seen. For 
example, 
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class A * A; 


first specifies A to be the name of a class and then redefines it as the name of a 
pointer to an object of that class. This means that the elaborated form class A 
must be used to refer to the class. Such artistry with names can be confusing and 
is best avoided. 


A typedef-name (§7.1.3) that names a class is a class-name; see also §7.1.3. 


m A nickname can be used to avoid problems caused by there being no effective way 
of making a class name local to a single compilation short of using local (§9.8) or 
nested classes (§9.7). Instead of declaring the class name static, as one could do 
for an object name, one can chose a name for the class that is almost certain not to 
clash with any other class name. Having done that, the typedef can be used to pro- 
vide a conveniently short name for use in the code. For example, 


class long name_that_will_not_clash_with_anything; 


class long_name_that_will_not_clash_with_anything f | 
EF as 
MF 


typedef long name that_will not_clash_with_anything X; 


// from now on we'll just call it ‘XxX’ 


9.2 Class Members 


member-list: 
member-declaration member-list.., 
access-specifier : member-list,y, 


member-declaration: 
decl-specifiers,,, member-declarator-list,., ¢ 
function-definition jo, 
gualified-name ; 


member-declarator-list: 
member-declarator 
member-declarator-list , member-declarator 


member-declarator: 
declarator pure-specifier,., i 
identifier o» : Constant-expression 


pure-specifier: 
=0 


A member-list may declare data, functions, classes, enumerations (§7.2), bit- 
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fields (§9.6), friends (§11.4), and type names (§7.1.3, §9.1). A member-list may 
also contain declarations adjusting the access to member names; see §11.3. A 
member may not be declared twice in the member-list. The member-list defines the 
full set of members of the class. No member can be added elsewhere. 


m This means that 


class X { 
int i; 
int i; // error: redefinition 
int j? 
); 
ant X: kr; // error: attempt to define member 


// outside class declaration 


exhibits two errors. 
The rule against double declarations also applies to function members: 


class Y { 


£(); 
f£() { /* ... */ ) // error: redeclaration 


}; 


D 


Note that a single name can denote several function members provided their 
types are sufficiently different (§13). 


m Note that a name cannot denote both a function and a data member. 


class Y { 

int f(); 

TR AE // error 
Me 


This could be made to work but only at the expense of a major complication of the 
overloading resolution rules. Consider 
struct Z { 


int: £()}; 
int (*f)(); // error 


}; 


void g(Z* p) 


{ 
p->f(); // would have been ambiguous 


} 


The same restriction against overloading nonfunction names applies to nonmember 
objects. For example, 


int glob(); 
int (*glob) (); // error 
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void h() 
{ 

glob(); // would have been ambiguous 
} 


o 


Note that a member-declarator cannot contain an initializer (§8.4). A member can 
be initialized using a constructor; see §12.1. 

A member may not be auto, extern, or register. 

The decl-specifiers can be omitted in function declarations only. The member- 
declarator-list can be omitted only after a class-specifier, an enum-specifier, or 
decl-specifiers of the form friend elaborated-type-specifier. A pure-specifier 
may be used only in the declaration of a virtual function (§10.2). 

Members that are class objects must be objects of previously declared classes. 
In particular, a class cl may not contain an object of class cl, but it may contain 
a pointer or reference to an object of class cl. 


m Since a class is defined immediately after the closing brace (}) has been seen the 
following is allowed: 


struct Y-i 
int i; 
}) ml, m2 = { sizeof(Y) }, m3 = m2; 


Before the end of the declaration of a class, its name can be used only where its size 
need not be known. For example, 


class X { 
X(); 
X* p; 
X& r; 
static X a; // a declaration; NOT a definition 
X £(); 
void g(X); 
int h() { return sizeof(x); } 
l); 


It may look as if the definition of X::h() uses the size of X before the end of the 

declaration of X, but because definitions of inline functions are not type checked 

until after the complete class declaration has been seen (§9.3.2), that is not the case. 
Consider also 


class Z { 
int i; 
enum { e = sizeof(Z); ); // error: Z undefined 
int f(int i=sizeof(Z)); // error: Z undefined 
int g(int i=sizeof(Z)) {} // error: Z undefined 


void h(int i) { i=sizeof(Z); } // ok 
Z() : i(sizeof(Z)) {} // ok 





f 
| 
| 
f 
f 
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When an array is used as the type of a nonstatic member all dimensions must be 
specified. 


W In particular, the old C trick of declaring a structure with an empty array as its last 


member — and later using that array to access space beyond the end of the object — 
is illegal. 


struct trick { 
// some members 
char vf); // error 
charé access(int i) 


{ 


return v[i]; // access beyond the end of object 
) 
); 


One practical reason for this restriction is that this trick (in any of its many forms) 
causes chaos where derived classes and virtual functions are used. In particular, the 
pointer to the table of virtual functions is often placed at the end of an object. Thus, 


Struct trick { 
virtual f(); 


char v[]; // error 
char& access(int i) 
{ 


return v{i}); // access beyond the end of object 
) 
Me 


would leave that pointer as the first four characters of trick: :v. 
Note that similar tricks involving access beyond the end of an array are equally 
suspect in relying on undefined behavior (§5.9). A safer alternative is 


struct ok { 
// some members 
ok(int s) : sz(s), v(new char[s]) { } 


char* v; 
unsigned sz; 


chará access(int i) 
{ 
return v[i]; // ok 
} 
}; 


A simple example of a class declaration is 
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struct tnode { 
char tword[20); 
int count; 
tnode *left; 
tnode *right; 
}; 


which contains an array of twenty characters, an integer, and two pointers to similar 
structures. Once this declaration has been given, the declaration 


tnode s, *sp; 


declares s to be a tnode and sp to be a pointer to a tnode. With these declara- 
tions, sp->count refers to the count member of the structure to which sp 
points; s.left refers to the left subtree pointer of the structure s; and 
s.right-—>tword[0] refers to the initial character of the tword member of the 
right subtree of s. 

Nonstatic data members of a class declared without an intervening access- 
specifier are allocated so that later members have higher addresses within a class 
object. The order of allocation of nonstatic data members separated by an access- 
specifier is implementation dependent (§11.1). Implementation alignment require- 
ments may cause two adjacent members not to be allocated immediately after each 
other; so may requirements for space for managing virtual functions ($10.2) and 
virtual base classes (§10.1); see also §5.4. 


m See also §11.1. O 


A function member (§9.3) with the same name as its class is a constructor 
(§12.1). A static data member, enumerator, member of an anonymous union, or 
nested type may not have the same name as its class. 


9.3 Member Functions 


A function declared as a member (without the friend specifier, $11.4) is called a 
member function, and is called using the class member syntax (§5.2.4). For exam- 


ple, 


struct tnode { 

char tword[20]; 

int count; 

tnode *left; 

tnode *right; 

void set(char*, tnode* 1, tnode* r); 
)e 


Here set is a member function and can be called like this: 


TRE i 


174 Classes Chapter 9 


void f(tnode nl, tnode n2) 
{ 
nl.set ("abc",&n2,0); 
n2.set ("def",0,0); 
} 


The definition of a member function is considered to be within the scope of its 
class. This means that (provided it is nonstatic §9.4) it can use names of members 
of its class directly. A static member function can use only the names of static 
members, enumerators, and nested types directly. If the definition of a member 
function is lexically outside the class declaration, the member function name must 
be qualified by the class name using the : : operator. For example, 


void tnode::set(char* w, tnode* 1, tnode* r) 
{ 

count = strlen(wtl); 

if (sizeof (tword) <=count) 

error("tnode string too long"); 

strcpy (tword,w) ; 

left = 1; 

right = r; 
} 


The notation tnode: : set specifies that the function set is a member of and in 
the scope of class tnode. The member names tword, count, left, and 
right refer to members of the object for which the function was called. Thus, in 
the call nl. set ("abc", &n2,0), tword refers to nl.tword, and in the call 
n2.set ("def",0,0) it refers to n2.tword. The functions strlen, error, 
and strcpy must be declared elsewhere. 


” 


m@m Member functions are sometimes referred to as ‘‘methods."’ This terminology 
comes from Smalltalk, where calling a member function is referred to as ‘‘sending a 
message.’ The analogy is not exact because of the reliance static type checking in 
Ch; the analogy between methods and member functions is somewhat more accurate 
for virtual functions (§10.2). Similarly, the Smalltalk phrase “instance variable™ is 
sometimes used to mean data member. O 


Members may be defined (§3.1) outside their class declaration if they have 
already been declared but not defined in the class declaration; they may not be 
redeclared. See also §3.3 and §9.3. Function members may be mentioned in friend 
declarations after their class has been defined. 


m Why can’t functions be added to a class after the end of the class declaration? If 
this were allowed, a user could gain access to a class simply by declaring an addi- 
tional function. 
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class X { 

int a; // accessible only by X::f() 
public: 

£0); Al 
Me 


int X::hijack() 
{ 
return at+; // error: ‘hijack’ not a member of X 


} 


This would, in particular, invalidate the desirable property that a C+ class contains 
the complete list of functions that can use private members. This property is impor- 
tant for debugging and for understanding a program in general, A class declaration 
is the complete specification of the interfaces provided by a class. If it were possi- 
ble to add functions later this would not be the case. Similarly, it is not possible to 
specify properties of a class, such as what base classes and members it has, before 
the class declaration itself. For example, 


class circle : public shape; // error 


void f(circle* p) 


{ 
// use shape attributes of '‘p’ 


) | 
See also $11.4. Allowing such techniques is technically feasible, but undesirable 
since it would require both the compiler and the programmer to keep track of par- 
tially specified classes. 

If a function is explicitly declared friend (§7.1.5), it is not a member of the 
class in which the friend declaration occurs, though it may be a member of some 
other class. Member functions may be explicitly declared inline (§9.3), static 
(§7.1.1), or virtual (§9.3). They have external linkage by default and may not be 
explicitly declared extern. 





class C [{ | 
friend f1(); // declare global fl() to be a friend i 
friend C2::f1(); // declare C2::f1() to be a friend 
inline f2(); 
static f£3(); 
virtual £5(); 
inline virtual f6(); 
extern f£7(); // error: ‘extern’ member 





}; 


o 
Each member function that is called must have exactly one definition in a program. 


m Only an inline member function can be defined in several translation units, and 
even then it is illegal to provide different definitions in different translation units. 
Allowing that would have opened the possibility of operations on a given object 
changing their meaning as the object was passed along from function to function. 
Worse, for virtual inline functions it would lead to the requirement that each object 
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could potentially carry around its own table of virtual functions so that identical 
operations on objects of (apparently) identical types would have different meanings. 
This is an unacceptable corruption of the notion of a type. O 


The effect of calling a nonstatic member function (§9.4) of a class X for some- 
thing that is not an object of class X is undefined. 


m For example, 
((X*)0)->f(); 


is not guaranteed to work. In particular, this will not work for virtual functions on 
any implementation since the information needed to find the appropriate virtual func- 
tion for an object of type X is not found at location 0. Even for nonvirtual func- 
tions, one should expect this trick to fail eventually because specialized CH imple- 
mentations might assume something about the contents of objects even when calling 
nonvirtual functions. In particular, one might expect implementations instrumented 
for debugging, interpreters, and implementations supporting dynamic loading to be 
sensitive to “housekeeping” information placed in the objects by the compiler. 

Naturally, this trick would work only if £() either checks its this pointer 
before accessing any members or never uses any member of the object for which it 
was called. In the latter case, the function should have been declared static 
(§9.4). o 


9.3.1 The this Pointer 


In a nonstatic (§9.3) member function, the keyword this is a pointer to the object 
for which the function is called. 


m This means that within a member function of a class X, a member of a class X can 
be equivalently referred to as mem and this—>mem. This equivalence is rarely 
used explicitly, but consider the following: 


class X { 

int a; 
Public: 

X(int a) { this->a = a; } 
}: 


The most common explicit use of this is in linked list manipulations where this 
is added to the representation of some list. O 


m In many languages, notably Smalltalk, the equivalent construct for identifying the 
object for which a function is invoked is called self. O 


m The simplest way to implement a call to a member function is for a compiler tO 

třansform it into an ordinary function call in the generated code. A pointer to the 

object for which the member function is called — its this pointer — is needed. 
Given a class A, a call to the member function A: : £, for example, 
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A* pa; 
Ppa->f (2); 


could be transformed into 
f(pa,2); // generated code 


This implies that calling a C+ member function does not incur run-time over- 
heads compared to a C function call. In particular, since a call of a member func- 
tion may cross a protection boundary (as defined by the access rules of a class; see 
§11) the access control mechanisms do not imply a run-time cost. On some machine 
architectures, the efficiency of the code generated for member function calls can be 
improved if the compiler passes the this pointer in a register. O 


The type of this in a member function of a class X is X *const unless the 
member function is declared const or volatile; in those cases, the type of 
this is const X *const and volatile X *const, respectively. A function 
declared const and volatile has a this with the type const volatile X 
*const. See also §18.3.3. For example, 


struct s { 

int: ‘ay 

int £() const; 

int g() { return at++; } 

int h() const { return att; } // error 
}; 


int s::f() const { return a; } 


The a++ in the body of s: :h is an error because it tries to modify (a part of) the 
object for which s::h() is called. This is not allowed in a const member func- 
tion where this is a pointer to const, that is, *this is a const. 

A const member function (that is, a member function declared with the 
const qualifier) may be called for const and non-const objects, whereas a 
non-const member function may be called only for a non-const object. For 
example, 


void k(s& x, const s& y) 


{ 

x.£()7 

x.g(); 

y-f(); 

y-9(); // error 
} 


The call y.g() is an error because y is const and s::g() is a non-const 
member function that could (and does) modify the object for which it was called. 

Similarly, only volatile member functions (that is, a member function 
declared with the volatile specifier) may be invoked for volatile objects. A 
member function can be both const and volatile. 
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w In early implementations of CH, this was non-const, and assignment to this 
in constructors and destructors had special meaning; see §18.3. The techniques rely- 
ing on assignment to this proved error-prone and have been replaced by user- 
defined free store management through class specific operator new() and 
operator delete () functions (§12.5). O 


Constructors (§12.1) and destructors (§12.4) may be invoked for a const or 
volatile object. Constructors (§12.1) and destructors (§12.4) cannot be declared 
const or volatile. 


9.3.2 Inline Member Functions 


A member function may be defined (§8.3) in the class declaration, in which case it 
is inline (§7.1.2). Defining a function within a class declaration is equivalent to 
declaring it inline and defining it immediately after the class declaration; this 
rewriting is considered to be done after preprocessing but before syntax analysis 
and type checking of the function definition. Thus 


int b; 

struct x { 
char* £() { return b; ) 
char* b; 

}; 


is equivalent to 


int b; 

struct x { 
char* f£(); 
char* b; 

}; 


inline char* x::f() { return b; } // moved 


Thus the b used in x: :£() is X::b and not the global b. 


m Note that this ‘‘rewriting’’ is a semantic notion and not a prescription for a partic- 
ular implementation. 

This rewriting rule implies that an inline function may refer to members declared 
lexically after it in the class declaration. This allows even mutually recursive func- 
tions to be written without forward declarations. 


class X ( 
void f() { g0); ) 
void g() { £(); } 
}; 


This is desirable, because the rule against double declarations of class members 
(§9.2) prevents forward declarations from being used. 
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class X { 

void g(); 

void f() { gf); ) 

void g() { f£(); } // error: double declaration of ‘g’ 
he 


o 


Member functions can be defined even in local or nested class declarations 
where this rewriting would be syntactically illegal. See §9.8 for a discussion of 
local classes and §9.7 for a discussion of nested classes. 


9.4 Static Members 


A data or function member of a class may be declared static in the class 
declaration. There is only one copy of a static data member, shared by all objects 
of the class in a program. A static member is not part of objects of a class. Static 
members of a global class have external linkage (§3.3). The declaration of a static 
data member in its class declaration is nor a definition. A definition is required 
elsewhere; see also §18.3. 


m This implies that one can declare static members of a class without having access 
to its definition. For example, 


class X; 


class Y { 

public: 
static class X sx; 
SD KE 

iz 


A static data member is a separate object. In particular, a static member is not 
const just because some object of the class of which it is a static member is 


const. 
Class: Ad fPices eats 
const Y a; 
¥ be 
void £(X& xx) 
{ 
Yiisx = XX; // ok 
} 
o 


A static member function does not have a this pointer so it can access non- 
static members of its class only by using . or —>. A static member function can- 
not be virtual. There cannot be a static and a nonstatic member function with 
the same name and the same argument types. 
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Static members of a local class (§9.8) have no linkage and cannot be defined 
outside the class declaration. It follows that a local class cannot have static data 
members. 

A static member mem of class cl can be referred to as cl: :mem (§5.1), that 
is, independently of any object. It can also be referred to using the . and -> 
member access operators (§5.2.4). When a static member is accessed through a 
member access operator, the expression on the left side of the . or -> is not 
evaluated. The static member mem exists even if no objects of class cl have been 
created. For example, in the following, run_chain, idle, and so on exist even 
if no process objects have been created: 


class process { 
static int no_of processes; 
static process* run_chain; 
static process* running; 
static process* idle; 
// 

public: 
// 
int state(); 
static void reschedule(); 
// 

}; 


and reschedule can be used without reference to a process object, as follows: 


void f() 


{ 
process: :reschedule(); 


) 


Static members of a global class are initialized exactly like global objects and 
only in file scope. For example, 


void process::reschedule() { /* ... */ }; 

int process::no of processes = 1; 

process* process::running = get_main(); 
process* process::run_chain = process: :running; 


Static members obey the usual class member access rules (§11) except that they can 
be initialized (in file scope). 

The type of a static member does not involve its class name; thus the type of 
process :: no_of processes is int and the type of &process :: 
reschedule is void(*) (). 


m The use of the word static to indicate that a member of a class is not associ- 
ated with an individual object of a class (and not replicated in each object) parallels 
the use of the word static to indicate that only one copy of a local variable is to 
be used for all calls of a function. For data members, this means that the member 
has the storage class static (§3.5); it still has external linkage (§3,3), though. 


{ 
$ 
f 
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The purpose of static members is to reduce the need for global variables by 
providing alternatives that are local to a class. A static member function or vari- 
able acts as a global for members of its class without affecting the rest of a program. 
In particular, its name does not clash with the names of global variables and func- 
tions or with the names of members of other classes. The association between the 
static members and their class is explicit and obvious, whereas the use of global 
variables and functions for similar purposes is neither. O 


m One could consider allowing initializers for data members within a class declara- 
tion. For example, 


class X { 
static int xl = 1; // error 
static const int x2 = 2; // error 
Static int x3 = sqrt(2); // error 
static const int x4 = sqrt(2); // error 
tL Seren 


J; 


The problem is that class declarations typically appear in header files, so a declara- 
tion like the one above will be seen by a compiler many times while compiling a 
multifile program. Especially when dealing with general initializers, it is important 
that there is exactly one definition of an object in a program. Allowing examples 
like the ones above would complicate separate compilation. 

Allowing examples, such as X::x1 above, where the complications are minor 
would introduce a complication into the language that does not seem to provide 
benefits commensurate with the confusion it would cause by allowing initializers for 
member declarations in a few selected cases. Also, many such special cases can be 
handled by using an enumerator instead of a const. 

class Y { 


enum ( yl = 1 }; // Y::yl is the constant 1 
}; 


9.5 Unions 


A union may be thought of as a structure whose member objects all begin at offset 
zero and whose size is sufficient to contain any of its member objects. At most 
one of the member objects can be stored in a union at any time. A union may 
have member functions (including constructors and destructors), but not virtual 
(§10.2) functions. A union may not have base classes. A union may not be used 
as a base class. 


m Since a union is fundamentally a low-level construct for saving storage, there 
seems little reason to support the derived class mechanisms for it. Consider, for 
example, allowing a union as a base class. How would the overriding of virtual 
functions (§10.2) be handled? Two members of the union may have completely dif- 
ferent sets of virtual functions. O 
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An object of a class with a constructor or a destructor or a user-defined assignment 


operator (§13.4.3) cannot be a member of a union. A union can have no static 
data members. 


m It would do no good to be able to define a union member function virtual 
since a union cannot be a base class. $ 

The rule against unions of classes with constructors or destructors can be a nui- 
sance, especially when dealing with software — such as YACC — that require the use 
of unions. The rule is necessary, though, because member functions for a class that 
has constructors usually rely on being invoked on objects that have been correctly 
constructed. In particular, the invocation of assignment operators and destructors on 
something that has not been correctly constructed will usually cause a disaster. 

Where necessary, one can separate the representation of a class from its opera- 
lions using a derived class (§10) like this: 


struct Xrep { // traditional C structure 
// can be put in a union 
// data members only 
}; 


class X : private Xrep { // C++ class with functions 
// maintaining proper consistency 
// of the representation 
// constructors, destructors, 
Me 


Naturally, this technique must be used with care, but doing so in stylized tools like 
YACC is quite feasible. O 


A union of the form 


union { member-list } ; 


is called an anonymous union; it defines an unnamed object (and not a type). The 
names of the members of an anonymous union must be distinct from other names 
in the scope in which the union is declared; they are used directly in that scope 
without the usual member access syntax (§5.2.4). For example, 


void f() 
{ 
union { int a; char* p; }; 
a=1; 
It se 
p = "Jennifer"; 
IE pede 


} 


Here a and p are used like ordinary (nonmember) variables, but since they are 
'union members they have the same address. 
A global anonymous union must be declared static. 


a 
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m Suppose no storage class specifier were required for a global anonymous union. 
What should be its linkage? Making it internal would make global anonymous 
unions differ from all other variables. If the default were external, an implementa- 
tion would have to ensure that each member name match only the same name in an 
identical anonymous union. This could be difficult and might become either a 
bottleneck for portability or a source of incompatibilities between implementations. 
Requiring that a global anonymous union be explicitly declared static allows the 
language to provide global anonymous unions without having the user worry about 
surprising side effects. O 


An anonymous union may not have private or protected members (§11). 
An anonymous union may not have function members. 


m Note that ordinary unions may have member functions. In particular, constructors 
can be most useful for defining suitable initialization for a union. For example, 


union u { 
int i; 
char c; 
char* p; 

| atine ii) { 1 = i121; } 

u(char cc) { € = cc; } 
u(char*® pp) { p= pp; } 

Ke 


uul = 1; // ul.i=i1 
U U2 = 71"? FE Deserve £14 
u v2 = 21"; Th Us p= SES 


Ordinary unions may have also have private members. 


union u { 
private: 
int 4; 


Me 


This is not assumed to be a very important or useful feature. It is simply easier to 
allow it than to disallow it. O 


A union for which objects or pointers are declared is not an anonymous union. 
For example, 
union { int aa; char* p; } obj, *ptr = &obj; 
aa = 1; // error 
ptr->aa = 1; // ok 
The assignment to plain aa is illegal since the member name is not associated with 


any particular object. 
Initialization of unions that do not have constructors is described in §8.4.1. 


wad 
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9.6 Bit-Fields 
A member-declarator of the form 
identifier,,, : constant-expression 


specifies a bit-field; its length is set off from the bit-field name by a colon. Alloca- 
tion of bit-fields within a class object is implementation dependent. Fields are 
packed into some addressable allocation unit. Fields straddle allocation units on 
some machines and not on others. Alignment of bit-fields is implementation 
dependent. Fields are assigned right-to-left on some machines, left-to-right on oth- 
ers. 

An unnamed bit-field is useful for padding to conform to externally-imposed 
layouts. As a special case, an unnamed bit-field with a width of zero specifies 
alignment of the next bit-field at an allocation unit boundary. 

A bit-field must have integral type (§3.6.1). It is implementation dependent 
whether a plain (neither explicitly signed nor unsigned) int field is signed or 
unsigned. The address-of operator & may not be applied to a bit-field, so there are 
no pointers to bit-fields. Nor are there references to bit-fields. 


m The layout of bit-fields is highly implementation dependent, and it is wise not to 
make any assumptions about it unless absolutely necessary. In particular, bit-fields 
are often used to specify access to memory locations where the underlying hardware 
assigns special meaning to different bits. For example, consider the memory used 
for I/O control in a machine: with memory mapped I/O or words set aside for the 
interrupt system. Such use is inherently implementation dependent. 

To enable such use, an implementation must carefully document how the layout 
of structures is done. In particular, for bit-fields a user needs to know whether a 
plain int bit-field is signed or unsigned and whether bit-fields are allocated 
from high-order to low-order bit or from low-order to high-order bit in a word. In 
general, how an implementation treats a plain bit-field will depend on what opera- 
tions the target hardware does most efficiently. 

Further, an implementation should specify how a bit-field that does not fit adja- 
cent to a previously allocated field in a suitably sized and aligned storage unit will 
be handled. Consider 


struct bits { 
int bl: 24; 
int b2: 16; 
int b3: 24; 
Me 


On a machine with 32-bit words that allocates from low-order to high-order, the 
object might be allocated in adjacent words, like this: 


Section 9.6 Bit-Fields 185 


unused bl 
nN 24/23 o 


or like this: 


b2 b 


n ujn 


unused 
u u 
0 





w 
= 
< 
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Unlike ANSI C, which restricts bit-fields to int, signed int, or unsigned 
int, C+ allows a bit-field to be of any integral type. That is, a bit-field may be 
char, short, int, long, any of their signed and unsigned varieties, or an 
enumeration type. 

People often try to use bit-fields to save space. Such efforts are often naive and 
can lead to waste of space instead. Using a two bit field instead of an eight bit 
char is a saving only if one can find other small fields to pack into that char. 
Even packing several small data items into a single word rather than using several 
words can be a loss in both run-time and space. On many machines a byte or a 
word is the smallest amount of memory that can be accessed without extra overhead. 
Extracting a bit-field may involve extra cycles and more often than not also extra 
instructions. Saving a byte of memory for storing an object may be more than offset 
by having to store and execute an extra instruction to extract the field from the smal- 
lest directly addressable unit of memory in which the object is allocated. O 


9.7 Nested Class Declarations 


A class may be declared within another class. A class declared within another is 
called a nested class. The name of a nested class is local to its enclosing class. 
The nested class is in the scope of its enclosing class. Except by using explicit 
pointers, references, and object names, declarations in a nested class can use only 
type names, static members, and enumerators from the enclosing class. 
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int x; 
int y; 
class enclose { 
public: 
int x; 
static int s; 


class inner { 


void f(int i) 


{ 
x = i; // error: assign to enclose::x 
s=i; // ok: assign to enclose::s 
::x = i; // ok: assign to global x 
Veer // ok: assign to global y 
} 
void g(enclose* p, int i) 
{ 
p->x = i: // ok: assign to enclose::x 
) 


}; 
inner* p = 0; // error ‘inner’ not in scope 
m The rules for nested classes mark a change from earlier versions of CH, and the 


rule that class names obey exactly the same rules as other names is not compatible 
with C. For example, 


struct X { 
stroct Y ATZARS */ Jz 
Me 
struct Y a; /* C, but not C++ */ 
X2:¥ b; // C++, but not C 


The reason for the change was that the lack of proper name scope nesting was caus- 
ing absurdities. In C, a struct cannot have member functions and thus does not 
need to establish a scope. In CH on the other hand, the class is the focus of pro- 
gramming and the context for writing the most critical code. The C mule left a class 
as an incomplete scoping mechanism. This prevented CH programmers from main- 
taining locality within a class, which became intolerable. It is still not clear whether 
a coherent set of scope rules for CH could be designed based on the C rule that a 
struct is not a scope. It is clear, however, that such a set of rules would be so com- 
plicated that even expert CH programmers would be unable to predict reliably the 
meanings of nontrivial examples involving nested or local functions. 
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The current rules for nested classes are a reversion to the original (prerelease) 


definition of C+. They are also easier to implement than any rules based on the C 
tule. O 


m Note that simply declaring a class nested in another does not mean that the enclos- 


ing class contains an object of the enclosed class. Nesting expresses scoping, not 
containment of sub-objects. O 


Member functions of a nested class have no special access to members of an 
enclosing class; they obey the usual access rules (§11). Member functions of an 


enclosing class have no special access to members of a nested class; they obey the 
usual access rules. For example, 


class E { 
int x; 


class I { 
int y; 
void f(E* p, int i) 
{ 
p->x = i; // error: E::x is private 
) 
); 


int g(I* p) 
{ 
return p->y; // error: I::y is private 
) 
}; 


Member functions and static data members of a nested class can be defined in the 
global scope. For example, 


class enclose { 
class inner { 
static int x; 
void f(int i); 
}; 
); 


typedef enclose::inner ei; 
int ei::x = 1; 


void enclose::inner::f(int i) { /* ... */ } 


Like a member function, a friend function defined within a class is in the lexical 
scope of that class; it obeys the same rules for name binding as the member func- 
tions (described above and in §10.4) and like them has no special access rights to 
members of an enclosing class or local variables of an enclosing function (§11). 
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m For example, 


int a; 


class enclose { 


Public: 
int x; 
static y; 
class inner { 
int a; 
Static b; 
friend void f{inner* p, int i) 
{ 
p->a = i; 
a=2; // error: inner::a is not static 
b 1; // ok: inner::b is static 
x 4; // error: enclose::x 1s not static 
y 3; // ok: enclose::y is static 
) 
friend void g(inner*, int); 
Me 


he 


void g(enclose::inner* p , int i) 


{ 

pa = i; 

a=2; // ok: assign to ::a 

b=1; // error: inner::b is not in scope 

x = 3; // error: enclose::x is not in scope 

y = 4; // error: enclose::y is not in scope 

enclose::x = 3; // error: enclose::x is not static 

enclose::y = 4; // ok: enclose::y is static f 
j { 


A class can be declared within a function definition; such a class is called a local 
class. The name of a local class is local to its enclosing function. The local class 
is in the scope of the enclosing function. Declarations in a local class can use only 
type names, static variables, extern variables and functions, and enumerators 


9.8 Local Class Declarations : 
| 
from the enclosing scope. For example, | 
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int x; 

void £() 

{ 
static int s ; 
int x; 
extern int g(); 


struct local { 
int g() { return x; } // error: ‘x’ is auto 
int h() { return s; } // ok 
int k() { return ::x; } // ok 
int 1() { return g(); } // ok 

}; 

// 

} 


local* p = 0; // error: ‘local’ not in scope 


m Allowing reference to the enclosing function's automatic variables would imply 
the introduction of nested functions. C 


An enclosing function has no special access to members of the local class; it 
obeys the usual access rules (§11). Member functions of a local class must be 
defined within their class definition. A local class may not have static data 
members. 


m The reason for these restrictions is to avoid having to introduce a notation for 
defining static members and functions outside the declaration of a local class. Ena- 
bling such declarations would only encourage the writing of complicated local 
classes. O 


9.9 Local Type Names 


Type names obey exactly the same scope rules as other names. In particular, type 
names defined within a class declaration cannot be used outside their class. For 
example, 


class X { 
typedef int I; 
Class: Y {0 Annan N 
la; 

}; 


I b; // error 
Yc; // error 


The following rule limits the context sensitivity of the rewnte rules for inline 
functions and for class member declarations in general. A class-name or a 
typedef-name or the name of a constant used in a type name may not be redefined 


190 Classes Chapter 9 


in a class declaration after being used in the class declaration, nor may a name that 
is not a class-name or a typedef-name be redefined to a class-name or a typedef- 
name in a class declaration after being used in the class declaration. For example, 


typedef int c; 
enum { i= 1 }; 


class X { 
char v[i]; 
int f() { return sizeof(c); } 


char c; // error: typedef name 
// redefined after use 
enum { i = 2 }; // error: ‘i’ redefined after 


// use in type name ‘char[i]’ 


}; 
typedef char* T; 


struct Y { 
T a; 
typedef long T; // error: T already used 
T b; 

}; 


m One might consider resolving the examples above by stating unequivocally that 
class member names are always to be preferred over global names when interpreting 
class members, thus resolving X::£/() to retum sizeof (char) and T to long. 
If that were done, would the following be considered acceptable? 


typedef char* T; 


class Z { 
ant F t Tra P47 return a) } 
typedef int T; // note: illegal, a ‘what if’’ example 


Me 


Note that if the declaration of Z is allowed, but not the declaration of Y, the follow- 
ing absurdity results: 


typedef char* T; 


class Z { 
MB ot BE // error 
int f2() { Ta = 1; return 1; } // ok i 
T f3() { T a; return a; } // error AND ok 
typedef int T; // note: illegal, a ‘‘what if’’ example 
}: 
| 
j 
j 


The more restrictive rule was adopted to minimize confusion. A compiler might be 
able to unravel reliably examples like the one above if suitable rules were adopted, 
but people would not. O 
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m The scope rules for type names are identical to those for other names. Here are 
some examples: 


typedef int T2; 


struct $2 { 
struct Y { 
typedef char T2; 
T2 b; // a char 
l}; 
typedef long T2; 
T2 (cz //a long 
h: 


T2 a; // an int 


typedef int T3; 


Struct S3 { 
etruct T2 ( Je J7 ok 
T3 a, b; 


x.a = x.b; // legal 

T3 t? // legal, means int t; 

È = X.a? // error: ‘t’ is an int 
j2 and *x.a" iea S3: 








Commentary 





9.1c Interfaces 


C+ provides a single declaration for a class that acts as the interface to both users 
and implementers of the member functions. There is no direct support for the 
notions of *‘interface definition’’ and *‘implementation module." This implies that 
the size of every object is known to the compiler. This in tum implies that a CH 
program requires recompilation whenever changes are made to the private or 
protected parts, even though such changes apparently affect only the imple- 
menter of a class and not its users. 

The reason for this is to allow the use of genuine automatic, static, and member 
variables; that is, to be able to allocate and manipulate objects directly rather than 
through a pointer, The benefits of this — over the altemative approach pioneered 
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by Simula that allocates objects that are not of built-in types on the free store — are 
significant in both run-time and space. For example, 


#include <complex.h> 


void f/() 

{ 
complex x = 2; 
complex y = xt3; 
Hib Bes 

} 


Here x and y are allocated on the stack (saving memory management operations) 
and operations on these variables (for example, the plus operation above) are easily 
inlined to manipulate the representation of the objects directly. 

The C+ solution also implies a minimal space overhead. For example, 


class rectangle { 
complex top left; 
complex bottom_right; 
}; 


A rectangle requires exactly the space for two complex numbers, say four 
words. Had an indirection been required, a rectangle would have required a 
minimum of two additional words for the two indirections. Unless sophisticated 
optimizations were applied, three extra words would be needed for free store 
**housekeeping’’ (one in each complex object and one in the rectangle itself). The 
indirection needed to represent a local variable of type rectangle would com- 
plete the doubling of the size. Declaring a local variable of type rectangle 
would also imply three allocation and three deallocation operations — compared to 
zero for CH. 

Having objects be free of compiler-generated ‘‘housekeeping’’ information 
unless such information is essential greatly helps the passing of information 
between CH and other languages such as C and Fortran. In particular, passing 
pointers to data structures is trivial. 

Allocation of objects on the free store can lead not only to inefficiency, but also 
— in languages where the indirection is implicit — to a noticeable discontinuity in 
the semantics of assignment. Built-in types have copy semantics (that is, if a and 
b are ints, a=b copies the value of b into a) whereas user-defined types have 
pointer semantics (that is, if a and b are of a user-defined type such as complex, 
a=b makes a refer to the same object as b). In C+, copy semantics are used for 
both built-in and user-defined types. Pointer semantics for user-defined types can 
be implemented by overloading the assignment operator. 

The beneficial effects of dealing with objects only through pointers, such as 
minimal recompilation after changes to the class declaration, can be achieved in 
C+ for specific classes by not allocating static, automatic, or member objects of 
those classes and avoiding the use of inline for their functions. Tools such as 
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compilers and programs calculating minimal recompilation must be alert to these 
possibilities. 


batted 








10 


Derived Classes 








This chapter explains inheritance. A class can be derived from another class, 
which is then called a base class of the derived class. A class may be derived 
from one or more classes. The derived class inherits the properties of its base 
classes, including its data members and member functions. In addition, the 
derived class can override virtual functions of its bases and declare additional 
data members, functions, and so on. Access to class members is checked for 
ambiguity. 


Sharing among the (base) classes that make up a class can be expressed using 
virtual base classes. Classes can be declared abstract to ensure that they are 
used only as base classes. 


The final reference manual section of this chapter (§10.4) is a summary of the 
CH scope rules. 


The commentary sections at the end of this chapter discuss the run-time mechan- 
isms necessary to implement inheritance. 


10 Derived Classes 


A list of base classes may be specified in a class declaration using the notation: 


base-spec: 
: base-list 


base-list: 
base-specifier 
base-list , base-specifier 
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base-specifier: 
class-name 
virtual access-specifier,,, complete-class-name 


access-specifier virtual, complete-class-name 


access-specifier: 
private 
protected 
public 


The class-name in a base-specifier must denote a previously declared class (§9), 
which is called a base class for the class being declared. 


m Note that a class that has been named but not yet declared cannot be used as a 
base class (just as it cannot be used to declare variables — other than static members 
— until it has itself been declared). 


class X; 
class Y : public X { // error: X undeclared 

X a; // error: X undeclared 

Static X b; // ok: ‘static X’ is not a definition 
Ve 


A class is said to be derived from its base classes. For the meaning of access- 
specifier see §11. Unless redefined in the derived class, members of a base class 
can be referred to as if they were members of the derived class. The base class 
members are said to be inherited by the derived class. The scope resolution opera- 
tor :: (§5.1) may be used to refer to a base member explicitly. This allows access 
to a name that has been redefined in the derived class. A derived class can itself 
serve as a base class subject to access control; see §11.2. A pointer to a derived 
class may be implicitly converted to a pointer to an accessible unambiguous base 
class (§4.6). A reference to a derived class may be implicitly converted to a refer- 
ence to an accessible unambiguous base class (§4.6). 
For example, 


class base { 
public: 
int a, b; 


}; 


class derived : public base { 
public: 

int b, c; 
}; 
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void f() 

{ 
derived d; 
d.a = 1; 
d.base::b = 2; 
d.b = 3; 
d.c = 4; 


base* bp = &d; // standard conversion: 
// derived* to base* 
} 


assigns to the four members of d and makes bp point to d. 


m The terms base class and derived class were chosen in preference to the altema- 
lives superclass and subclass because of confusion experienced by Simula users 
about which was which. Similar problems have been observed among Object Pascal 
users. Part of the confusion stems from the observations that a superclass contains a 
subset of the attributes its subclasses and that a superclass can be represented as a 
sub-object of an object representing its subclass. This is one of C+’s few deliberate 
departures from Simula’s terminology. O 


A class is called a direct base if it is mentioned in the base-list and an indirect 
base if it is not a direct base but is a base class of one of the classes mentioned in 
the base-list. 

Note that in the class-name :: name notation, name may be a name of a 
member of an indirect base class; the notation simply specifies a class in which to 
start looking for name. For example, 


class A { public: void f(); }; 
class B : public A { ); 
class C : public B { public: void f(); }; 


void C::f() 

{ 
f£(); // Call C's £() 
A::£(); // call A's £() 
B: c£ () 7 /7acaliwa’ sfl) 

) 


Here, A: : f () is called twice since it is the only £() in B. 
Initialization of objects representing base classes can be specified in construc- 
tors; see §12.6.2. 


10.1 Multiple Base Classes 


A class may be derived from any number of base classes. For example, 
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class A { /* aA) EF 
class B { /* EAEN 
class CEU Eeay 
class D : public A, public B, public C { /* ... */ }; 


The use of more than one direct base class is often called multiple inheritance. 

The order of derivation is not significant except possibly for default initial- 
ization by constructor (§12.1), for cleanup (§12.4), and for storage layout (§5.4, 
§9.2, §11.1). The order in which storage is allocated for base classes is implemen- 
tation dependent. 

A class may not be specified as a direct base class of a derived class more than 
once but it may be an indirect base class more than once. 


class B { /* ... */ ); 

class D : public B, public B { /* ... */ }; // illegal 
classi L { /* .4..*/_)i 

class A : public L { /* ... */ }3 

class’ B e public L { /* ... */ };3 

class C : public A, public B { /* ... */ }; // legal 


Here, an object of class C will have two sub-objects of class L. 


m A derived class and its base classes can be represented by a directed acyclic graph 
(DAG) where an arrow means ‘‘derived from. A DAG of classes is often referred 
to as a ‘class lattice.’ It is often easier to understand complicated class lattices by 
drawing them. For example, 


L L 


l ! 
į N A s 
apas 
C 


Note that L is replicated. This diagram really shows the relationship between the 
sub-objects of an object of class C. The importance of this will become apparent by 
comparison with the example below. We draw derived classes below their bases to 
match the order in which their declarations are seen by a compiler and in which they 
appear in a printout of the program. 

Note also that such class DAGs are simply representations of classes used to 
ease understanding of the classes in a system and their relationships. Typically, an 
implementation does not supply a run-time structure that exactly matches the DAGs; 
that is, one cannot simply assume that for each arrow in the DAG there is a 
corresponding pointer in the representation of an object. On the contrary, typically 
such arrows represent information available to the programmer and the compiler, but 
not in the final object code. See §10.1 through §10.10 for an explanation of how 
one might handle the run-time aspects of inheritance. 0 
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@ The reason that a given class may not appear more than once in a list of base 
classes is that every reference to it or its members would be ambiguous. For exam- 
ple, . 


class B { public: int b; }; 
class D : public B, public B { }; // error 


void f(D* p) 
{ 

P->b = 7; // ambiguous 
} 


This problem does not arise when a class appears twice as an indirect base. An 
object of class C above has two L objects: A: :L and B: :L, which might be laid out 
in memory like this: 


L part (of A) 








If these declarations come from an implementation of lists requiring each ele- 
ment to contain a link, and if L is a link class, then a C object can be on a list of As 
and also on a list of Bs. 

Now suppose class L has a member next. How could a function C::£() refer 
to L::next? Obviously, 


void C::f() { next = 0; } 4/ error 


is ambiguous; is A: :next to be set, or B: :next, or both? Explicit qualification 
must be used, for example, 


void C::f() { A::next = B::next; } 
Because there are two L objects in a C object, casting (either implicit or explicit) 


between a pointer to an L and a pointer to a C is ambiguous, and therefore disal- 
lowed. 
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C* pe = new C; 
L* pl = pe; // error: ambiguous 
pl = (L*) pe; // error: still ambiguous 


The following casts are unambiguous and may be used: 


pl = (L*) (A*)pe; // cast to the L in C's A 
pe = (C*) (A*)pl; // cast to the C containing A’s L 


Now consider a function expecting an L argument. 
extern f(L*); 
Because an A is also an L, f () can be called with an A object, as follows: 


Aa 
£(&a); // £f will use A's L 


On the other hand, because a C contains two L objects, £() cannot be passed a C. 
Casting the C object to an A before the call will disambiguate. 


Cut; 
f£(&c); // error: ambiguous 
£((A*) &c); // f will use the Lin C's A 


o 


The keyword virtual may be added to a base class specifier. A single sub- 
object of the virtual base class is shared by every base class that specified the base 
class to be virtual. For example, 


crass VET T/E cn AAS; 

class A : virtual public V { /* ... */ }; 
class B : virtual public V { /* ... */ ); 
class C : public A, public B { /* ... */ }; 


Here class C has only one sub-object of class V. 


m Or graphically (in contrast to the C, A, B, L example above), 


ae 
Ses 


One important aspect of multiple inheritance as compared to single inheritance is 
that classes within a class lattice can share information without pushing that informa- 
tion towards the single root of an inheritance tree. With multiple inheritance in gen- 
eral and virtual base classes in particular it is possible for what we'll call ‘‘sibling 
classes,” like A and B in the example above, to share information without affecting 
other classes in an inheritance lattice. This counteracts the tendency observed in sin- 
gle inheritance systems (such as C before the introduction of multiple inheritance) 
for information to drift toward the top of the tree. In effect, the root node of a 


Section 10.1 Multiple Base Classes 201 





single inheritance tree acts as a global name space for all classes in an inheritance 

tree and can suffer from a phenomenon observed in languages without inheritance, 

which is that all interesting information ends up being global. 

A virtual base class provides a local point for sharing information, thus improv- = 

ing locality of reference and data hiding beyond what can be achieved without such 

classes. A virtual base class provides a statically typed interface to the information 

shared by its derived classes. Since a virtual base class is a perfectly ordinary C++ 

class, all the features of the language are available for expressing this sharing. In 

particular, virtual functions can be defined for a virtual base class; see §10.10. O 


A class may have both virtual and nonvirtual base classes of a given type. 


Class B {( /* aue SA 33 

clasg X. ; virtual public B (A EAA; 

Class Y 3 virtual public B { /* 22. S/Y; 

class Zs. public: B { /* 2... t/y 

class AA : public X,- public Y, public z p /* 2254/2); 


Here class AA has two sub-objects of class B: Z's B and the virtual B shared by X 
and Y. 


m Or graphically, 


aa 


& 


N —> 


B 
Y. 
AA 

m Because one wants to avoid undesired multiple calls of a function in a virtual 
class, programming using virtual bases can be more difficult than programming using 
nonvirtual bases. The example below shows one style for programming with virtual 

bases. : 
Let each class provide a protected function, _f (), doing the part of an operation 


f() that specifically relates to the class, and a public function f() calling _f/) 
and the _ f ()s for its base classes. 


class W { 
protected: 5 
void _f() { /* code for what W needs to do */ } 
PETE 
public: 
void f() {_f0;) 
TI ove 
}; 
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class A : public virtual W { 


protected: 
void _f() { /* code for what A needs to do */ } 
ELS 
public: 
void £() ({ _f(); W::_f(); } 
SI tress 
Me 
class B : public virtual W { 
protected: 
void _f() { /* code for what B needs to do */ } 
IS Oe 
Public: 
void EN { £07 W: T(z} 
PLETE 
}; 
class C : public A, public B, public virtual W [ 
protected: 
void _f() { /* code for what C needs to do */ } 
fi asa 
public: 
vold £() f _f£()7 A LN Bes EOF We: FQ? j 
BS ic 
jy 


Additional support for programming using multiple inhentance, such as the method 
combination schemes in some Lisp dialects, was considered. None of the alterna- 
tives considered, however, seemed simple, general, and efficient enough to justify 
the complexity they would add to CH. In particular, it was not obvious how to 
combine the C+ strong static type checking with a scheme flexible enough to sup- 
port directly the *‘mix-in"’ style of programming used in some Lisp dialects. O 


10.1.1 Ambiguities 


Access to base class members must be unambiguous. Access to a base class 
member is ambiguous if the expression used refers to more than one function, 
object, type, or enumerator. The check for ambiguity takes place before access 
control (§11). For example, 


class A { 
public: 

int a; 

int (*b) (); 
int £(); 
int f(int); 
int g(); 


Bess... 
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class B { 

int a; 

int b(); 
public: 

int £(); 

int g; 

int: ht); 

int h(int); 
}3 


class C : public A, public B {}; 


void g(C* pc) 

{ 
pe->a = 1; // 
pc->b(); // 
pe->£(); // 
pc->f (1); // 
pe->g(); // 
pe->g = 1; // 
pe->h(); // 
pe->h(1); // 

} 


If the name of an overloaded function is unambiguously found overloading resolu- 
tion also takes place before access control. 


error: 
error: 
error: 
error: 
error: 
error: 


ok 
ok 


ambiguous: 
ambiguous: 
ambiguous: 
ambiguous: 
ambiguous: 
ambiguous: 


> Ep >> > > 
agarose 
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or B::a 
or B::b 
or Bef 
or B::f 
or B::g 
or B::g 


@ Note that reaching the same object or enumerator doesn't imply an ambiguity. 


class A {í 
public: 
static a; 
enum { e }; 
J: 


class B : public A { }- 
class © : public AT }; 


class D : public B, public C { }; 


void g(D* pd) 
{ 
pd->a = 1; 


int i = pd->e; 


o 


// ok, 
// ok, 


‘a’ is static 
‘e’ is an enumerator 


Ambiguities can be resolved by qualifying a name with its class name. For exam- 


ple, 


ce ey O 
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class A { 
public: 

int £(); 
}; 


class B { 
public: 

Intec) 
3 


class C : public A, public B { 
int £() { return A::f() + B::f£(); ) 
}3 


When virtual base classes are used, a single function, object, type, or enumerator 
may be reached through more than one path through the directed acyclic graph of 
base classes. This is not an ambiguity. The identical use with nonvirtual base 
classes is an ambiguity; in that case more than one sub-object is involved. For 
example, 


class V { public: int v; }; 
class A { public: int a; }; 
class B : public A, public virtual V {}; 
class C : public A, public virtual V ({); 


class D : public B; public C { public: void f(); }; 


void D::f() 
{ 
vtt; // ok: only one ‘v’ in ‘D’ 
att; // error, ambiguous: two ‘a’s in ‘D’ 


) 


m Or graphically, listing member names within braces, 


A { a} Viet ovil} Aafia} 


A pd 


o 
a 


When virtual base classes are used, more than one function, object, or enumerator 
may be reached through paths through the directed acyclic graph of base classes. 
This is an ambiguity unless one of the names found dominates the others. The 
identical use with nonvirtual base classes is an ambiguity; in that case more than 
one sub-object is involved. 


o 


i 
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A name B::f dominates a name A: :f if its class B has A as a base. If a 
name dominates another no ambiguity exists between the two; the dominant name 
is used when there is a choice. For example, 


class V { public: int £(); int x; }; 
class B : public virtual V { public: int £(); int x; }; 
class C : public virtual V { }; 


class D : public B, public C { void g({); }; 


void D::g() 
{ 


xt++; 
£(); 


m Or graphically, 


// ok: B::x dominates V::x 
// ok: B::£() dominates V::f() 


Note that dominance applies to names and not just to functions. 

The dominance rule is necessary for virtual functions — since it is the rule for 
which function should be invoked for a virtual call — and experience showed it 
applying nicely to nonvirtual functions as well. Early use of a compiler that did not 
apply the dominance rule to nonvirtual functions led to programmer errors and con- 


torted programs. 


For virtual functions, the dominance rule is what guarantees that the same func- 
tion is called independently of the static type of the pointer, reference, or name of 
the object for which it is called. 

Note that in the following example A2::£() dominates A1: :f() in both calls: 


struct Al { int f(); }; 


struct A2 : 
struct A3 : 
: A3 , virtual Al { }; 


struct A4 


virtual Al { int f£(); J; 
A2 { ); 


void f(A2* pa2, A4* pad) 


{ 


pa2->f£(); // call A2::f{() 
pas->f£();  // call A2::f() 


) 


One might imagine that Al::£() was considered ‘‘closer to’? A4 and chosen for 
the call pa4->f() since Al is a direct base of A4 and A2 isn’t. This is not the 


case. Consider 
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eS 


A4 


Examining the DAG shows that A2: : f dominates Al: : f and would have been 
called had A1 : : f been virtual. 
See §10.8 for a key example where dominance is essential. O 


An explicit or implicit conversion from a pointer or reference to a derived class to 
a pointer or reference to one of its base classes must unambiguously refer to the 
same object representing the base class. For example, 


class V { }; 
class A { ); 
class B : public A, public virtual V { }; 
class C : public A, public virtual V [ }; 
class D : public B, public C { }; 
void g() 
{ 
D d; 
B* pb = &d; 
A* pa = &d; // error, ambiguous: C's A or B's A ? 
v* pv = &d; // fine: only one V sub-object 
} 


m Or graphically, 
A Vv A 
BEE es poe ere 
B C 
SS oe 
D 

Ambiguous uses of derived class members are detected at compile time. Only 
the use of a name in an ambiguous way is an error, however; combining classes that 
contain members with the same name in an inheritance scheme is not an error. 
Checking for ambiguity is done before access control or type checking (§10.1.1). 


Thus, an ambiguity exists when base class members have the same name, even if 
only one is accessible from the derived class. For example, 
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class A { public: int i; J; 
class B í private: char* i; ); 
class C : public A, public B { /* ... */ }; // OK 


C* cptr=new C; 
int j=cptr->i; // error: A::i or B::i ? 
Such ambiguities can be resolved using the :: operator, as follows: 
int j=cptr->A::i; // int i in the A part of C 
A similar ambiguity arises if both A and B have a function f (). 


class A { public: void f(); }; 
class B { public: int f£(); ÈE 
class C : public A, public B { /* ... */ I: // OK 


C* cptr=new C; 


void gl() 
{ 
C* cptr=new C; 


cptr->A::f(); // unambiguous: the f() in C’s A 
cptr->B::f£(); // unambiguous: the f£() in C’s B 
} 


One can also get an unambiguous call by restricting the context. 


A* aptr = cptr; // implicit conversion of C* to A* 
aptr->f(); // unambiguous: calls A::f{) 
void g2() 
{ 
C* cptr = new C; 
A* aptr = cptr; // implicit conversion of C* to A* 
aptr->f(); // unambiguous: calls A::f() 


} 


A major reason for virtual functions is to ensure that the same function is called for 
an object independently of the type of the expression used to access the object. 

Where possible, one should resolve such ambiguous calls by providing a function 
in the derived class. For example, 


class C : public A, public B { 
public: 
int f() { Az:f(); return B::f(); } 
Oh Ae 
Me 


void g3() 
{ 
C* cptr=new C; 
cptr->f(); // calls C::f 
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10.2 Virtual Functions 


If a class base contains a virtual (§7.1.1) function vf, and a class derived 
derived from it also contains a function v£ of the same type, then a call of v£ for 
an object of class derived invokes derived: : vf (even if the access is through 
a pointer or reference to base). The derived class function is said to override the 
base class function. If the function types (§8.2.5) are different, however, the func- 
tions are considered different and the virtual mechanism is not invoked (see 
also §13.1). It is an error for a derived class function to differ from a base class’ 
virtual function in the retum type only. For example, 


struct base { 
virtual void vfl(); 
virtual void vf2(); 
virtual void vf3(); 
void f(); 

}; 


class derived : public base { 
public: 
void vf1(); - 
void vf2 (int); // hides base::vf2() 
char vf3(); // error: differs in return type only 
void £(); 
l; 


void g() 
{ 
derived d; 
base* bp = &d; // standard conversion: 
// derived* to base* 


bp->vf1(); // calls derived::vf1 
bp->vf2(); // calls base: :vf2 
bp->£(); // calls base::f 


} 


The calls invoke derived: :vf1, base: :vf2, and base: : f, respectively, for 
the class derived object named d. That is, the interpretation of the call of a vir- 
tual function depends on the type of the object for which it is called, whereas the 
` interpretation of a call of a nonvirtual member function depends only on the type of 
the pointer or reference denoting that object. For example, bp->vf1() calls 
derived: :vf1() because bp points to an object of class derived in which 
derived: :vf1() has overridden the virtual function base: : vf1(). 


m This is the property that makes derived classes and virtual functions the key to the 
design of many CH programs. A base class defines an interface for which a variety 
of implementations are provided by derived classes. A pointer to an object of a 
class can be passed into a context where the interface defined by one of its basè 
classes is known but where the derived class is unknown. The virtual function 
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mechanism ensures that the object is still manipulated by the functions defined for it 
(and not just by the functions defined for the base class). Only functions specified 
in the interface provided by the base class will be called and only if the actual argu- 
ments match the formal arguments required. 

The use of derived classes and virtual functions is often called object-oriented 
programming. Furthermore, the ability to call a variety of functions using exactly 
the same interface — as is provided by virtual functions — is sometimes called 
polymorphism. 

A virtual function call is usually implemented as an indirect function call 
through a per class table of functions generated by the compiler; see §10.7 and 
§10.8. This ensures reasonable efficiency for such calls. O 


The virtual specifier implies membership, so a virtual function cannot be 
a global (nonmember) (§7.1.1) function. Nor can a virtual function be a static 
member, since a virtual function call relies on a specific object for determining 
which function to invoke. A virtual function can be declared a friend in another 
class. An overriding function is itself considered virtual. The virtual specifier 
may be used for an overriding function in the derived class, but such use is redun- 
dant. A virtual function in a base class must be defined or declared pure (§10.3). 


wm This ensures that undefined functions can be detected at link time so that a run- 
time check for undefined functions at each virtual function call is avoided. O 


A virtual function that has been defined in a base class need not be defined in a 
derived class. If it is not, the function defined for the base class is used in all calls. 


m When the exact type of an object is known at compile time, the virtual function 
call mechanism need not be used. Instead, an ordinary member function call can be 
used. In the example above, d. vf1() can be evaluated without resort to a virtual 
function call because d is an object of type derived, so derived: :vfl can be 
called directly. When a virtual function is called through a pointer or a reference, 
the actual type of the object is not necessarily known, so the virtual call mechanism 
must be used. A compiler with enough knowledge of control flow, however, can 
eliminate virtual function calls even in some of these cases, such as the calls through 
bp in the example above. 

A direct call is a few memory references more efficient than a virtual function 
call (see §10.7, §10.8, §10.10), but the real advantage of direct calls is for inline 
functions where the difference in run-time overhead can be significant. Inline virtual 
functions make perfect sense and are quite frequently used. Naturally, inlining is 
used only where the inline function is applied to an object of known type. As ever, 
it is wise to remember that overuse of inlining is self-defeating (see §7.1.2). O 


Explicit qualification with the scope operator (§5.1) suppresses the virtual call 
mechanism. For example, 
class B { public: virtual void f(); }; 
class D : public B { public: void f(); }; 


void D::f£() { /* ... */ B::f(); } 
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Here, the call of f in D really does call B: : f and not D: : f. 


m An unqualified call 
VOIA DESEN) a { t/ 8 ah aL.) pd 


would result in a recursive call of D: : f. 
Explicit qualification in user code is error prone and should be avoided wherever 
possible. For example, 


void g() 
{ 

B* p = new D; 

P->B::f(); // call B::f£(), sloppy code 
) 


Such use of explicit qualification scatters explicit knowledge of the details of the 
class declaration over the source code in a way that complicates code maintenance. 
As a rule of thumb, explicit qualification should be used only to access base class 
members from a member of a derived class. 


Consider 
class X { 
Public: 
virtual void f(int); 
virtual int g(); 
D 
Class Y : public X { 
public: 
void f(short); // hides base::f{() 
short g(); // error: differs in return type only 
); 


Here, the likely intent was for the functions in class Y to override the functions in 
class X. This will not happen, though, because the types do not match exactly. The 
mismatch of retum types for g() is simply an error and will be reported by the 
compiler. The argument type case is more subtle since the user might be trying tO 
do some form of overloading; a waming can be issued in most such cases. 0 


m CH requires an exact type match between a virtual function in a base class and a 
function overriding it in a derived class. Why couldn't the function be overridden 
by a function with a slightly different type? For example, why not allow this? 


class B { 
LLE 
public: 
virtual void f(B*); 


} 
i 
Mi i 
; 
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void h(D* p) 
{ 

D* p2 = p->f(); 
} 


instead of 


void h(D* p) 
{ 
D* p2 = (D*) p->f(); 
) ‘ 


Allowing this, however, would imply a complication of the function call/retum 
mechanism because a B* and a D* to the same object may not have the same abso- 
lute value. In particular, they will typically not have the same absolute value where 
B is a second or subsequent base of D. O 


@ There is a way that implicit conversions of a pointer to a derived class to a pointer 
to a base type can cause a run-time error. 


B* index(B* p, int i) 
{ 

: return &p[i]; 

} 


This innocent-looking code can be made to retum a pointer to something that isn't a 
B even without having i out of range: 


D v{10]; 


void bomb () 
{ 

B* p = index(v,2); 
} 


Here, the array name v is converted to a D*, which is then converted to a B*. 
Since sizeof (B)<sizeof(D), given the declarations above, the offset calcula- 
tion done by index () is all wrong, and the pointer retumed most likely points into 
the middle of some D object. : 

As mentioned elsewhere (§8.2.4), the C array concept is weak and beyond repair. 
The way to avoid this problem is to use a proper array object type such as the one 
presented in §14.2. O 


m CH does not contain a language-supported mechanism allowing a program to ask 
the question ‘‘of what class is this object really an object?” given only a pointer to 
a base class. There are two reasons for this. 

First, such a mechanism would require every object — or at least every object of 
a user-defined type — to contain information identifying its type. This requirement 
would compromise object layout compatibility with languages such as C and Fortran, 
which is too high a price to pay; see also §9.1. é 

Second, providing a simple, convenient, and efficient way of asking that question 
would enable a style of programming that relies on switching on a type field rather 
than using virtual functions. The observation that in Simula programs this style has 
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class D : public B { 
Uh pose 
void f(D*); // hides B::f(B*); 
// does not overide B::f(B*) 
// a warning would be appropriate 
int m; 


); 


After all, any D* also points to a B, and often that really would be useful. 

The reason is that if this were allowed a pointer to a base class could be impli- 
citly converted to a pointer to its derived class, which could have unfortunate conse- 
quences (see §10.4). Consider 


void g(B* pl, B* p2) 
{ 
pl->f (p2); // virtual call of f() 


} 
void h() 
{ 
g(new D,new B); 
) 


This would cause D: :f to be invoked with a pointer to a B as its second argument, 
which would make D::£() refer past the end of the B object when accessing 
members of D. 


void D::f(D* p) 
{ 

p->m = 7; 
} 


Consequently, an exact match on the types of all arguments is required when over- 
riding a virtual function. 

Then how about allowing a function returning a pointer to a base class to be 
overridden by a function retuming a pointer to a derived class? 


class B { 

PATEE 
public: 

virtual B* f(); 
}; 


class D : public B { 
D* £(); // error, but let’s for a moment suppose 


//we can do it 
}; 


That is safe because every D object contains a B object representing its base and 
would allow people to write code like this: 
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lead to messy, non-modular code strongly influenced the decision not to include such 
a facility in CH. 

On the other hand, the absence of such a facility renders some programming 
tasks — such as object input/output and dynamic linking - notably harder because 
the user is forced to provide a facility for object type identification explicitly. For 
example, 


class mybase { 


TSS 

Public: 
Static int rep; 
virtual int* mytype(); 
oy ae 

ie 


int* mybase::mytype() { return érep; } 


class myderivedl : public mybase { 
Fo ass 
public: 
Static int rep; 
int* mytype(); 
rf ae 
}; 


int* myderivedl::mytype() { return érep; } 


Given these definitions, a user can write 


void f(mybase* p) 
í 
if (p->mytype() == émyderivedl::rep) { 
Adios 
} 
) 


Writing such code is tedious and repetitive — and therefore open to mechanization. 
Naturally, programmers are tempted to store other useful information in the rep 
object. Further, different people invent different schemes for object type identifica- 
tion. The last point is the most troublesome since it creates a barmer to the sharing 
of programs. 

It has been repeatedly observed that a solution to the problem would be to define 
a standard class for containing ‘‘useful information about a class’’ and have com- 
pilers allocate one object of that class for each class used in a program. The com- 
piler could then provide an operation that, when applied to an object, retumed a 
pointer to the ‘‘descriptor object for the class much as the virtual function 
mytype () above retumed a pointer to an int. A class with no virtual functions 
would maintain object layout compatibility with other languages, and the type iden- 
tification operator could retum a value based on the class's static type. Only classes 
with virtual functions would allow the types of their objects to be identified at run- 
time given a pointer to a base class. 

The key problem in the design of such a scheme is to decide what ‘useful infor- 
mation"’ class descriptor objects should contain and what the interface for accessing 
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that information should be provided by a standard class descriptor class. O 


10.3 Abstract Classes 


The abstract class mechanism supports the notion of a general concept, such as a 
shape, of which only more concrete variants, such as circle and square, can 
actually be used. An abstract class can also be used to define an interface for 
which derived classes provide a variety of implementations. 

An abstract class is a class that can be used only as a base class of some other 
class; no objects of an abstract class may be created except as objects representing 
a base class of a class derived from it. A class is abstract if it has at least one pure 
virtual function. A virtual function is specified pure by using a pure-specifier 
(§9.2) in the function declaration in the class declaration. A pure virtual function 
need be defined only if explicitly called with the qualified-name syntax (§5.1). For 
example, 


elass Point (ZE 2.5 AA); 

class shape { // abstract class 
point center; 
// 

public: 
point where() { return center; } 
void move (point p) { center=p; draw(); } 
virtual void rotate(int) = 0; // pure virtual 
virtual void draw() = 0; // pure virtual 
// 

); 


An abstract class may not be used as an argument type, as a function return type, 
or as the type of an explicit conversion. Pointers and references to an abstract class 
may be declared. For example, 


shape x; // error: object of abstract class 
shape* p; // ok 

shape f(); // error 

void g (shape); // error 


shape& h(shape&); // ok 
Pure virtual functions are inherited as pure virtual functions. For example, 


class ab_circle : public shape { 
int radius; 
public: 
void rotate (int) {} 
// ab_circle::draw() is a pure virtual 


}; 


Since shape: :draw() is a pure virtual function ab_circle::draw() is 4 
pure virtual by default. The alternative declaration, 
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class circle : public shape { 

int radius; 
public: 

void rotate(int) (} 

void draw(); // must be defined somewhere 
}; 


would make class circle nonabstract and a definition of circle: :draw() 
must be provided somewhere. 


m Originally, it was required that pure virtual functions be either defined in a derived 

class or redeclared to be pure. Experience showed that programmers needed a pure 

virtual function as a pure virtual function in a derived class more often than they 

wanted to define it in the derived class. In other words, a common use of an 

abstract class turned out to be as a base class for yet another abstract class. 
Inheriting a pure virtual as a pure virtual is a safe default behavior. O 


Member functions can be called from a constructor of an abstract class; the 
effect of calling a pure virtual function directly or indirectly for the object being 
created from such a constructor is undefined. 


m A likely result of (indirectly) calling a pure virtual function for a partly con- 
structed object is a core dump. A compiler can wam against some, but not all, such 
calls. For example, 


class X [ 
virtual f() = 0; 
X(X* p) í 
£f(): // error: pure virtual called 


p->f(); // probably OK 
}; 
Me 


A compiler can easily detect the first call of X¥::£(). The second call of X::£() 
will be OK whenever the argument p points to an already created object of a class 
derived from class X. 

Note that a pure virtual can be defined. It can be called using explicit qualifica- 
tion only, as follows: 


class A { 
virtual void f() = 0; 
AQ { 
A::f(); // ok 
} 
}; 


void A::f() // defined somewhere 


{ 
DR 
) 


The reason this makes technical sense is that the explicit call A: :£() avoids use of 
the virtual call mechanism (§10.2) that cannot be used for a pure virtual function 
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from within the constructor. If A::f() calls a pureiyirtual epn A N ee 
then it in tum will encounter a disaster just as the constructor would j ie erie 
Structor for an abstract class will be called (only) in the process of creating : 


of a derived class. Such constructors can be useful and occasionally need to call 
member functions. o 


10.4 Summary of Scope Rules 


The scope rules for Ch programs can now be summarized. These rules P N 
formly for all names (including rypedef-names (§7.1.3) Bn eiss nameni AS l 
wherever the grammar allows such names in the context discussed by a particu ar 
rule. This section discusses lexical scope only; see §3.3 for an explanation of link- 
age issues. The notion of point of declaration is discussed in ($3.2). wE 

Any use of a name must be unambiguous (up to overloading) in its ee 
(§10.1.1). Only if the name is found to be unambiguous in its scope a an : 
Tules considered (§11). Only if no access control errors are found is the type o 
object, function, or enumerator named considered. 

a name used outside any function and class or prefixed by the unary ae 
operator :: (and not qualified by the binary :: operator s Rese S ii 
must be the name of a global object, function, or enumerator., 

A name specified i X: % after obj., where obj is an X or a powri of 
X, or after ptr->, where ptr is a pointer to X must be the pani eben a 
class X or be a member of a base class of X. In addition, ptr in ptr-> may o 
an object of a class yY that has operator-> () declared s 
ptr->operator->() eventually resolves to a pomer tos ean, hat is used 
A name that is not qualified in any of the ways described above ajd ; = a hit 
in a function that is not a class member must be declared in the block in s A 
occurs or in an enclosing block or be a global name. The declaration of a ie 
name hides declarations of the same name in enclosing blocks and global names. 
In particular, no overloading occurs of names in different scopes Shake rienced 
A name that is not qualified in any of the ways described above and a ae 
in a function that is a nonstatic member of class X must be declared in the 3 of 
which it occurs or in an enclosing block, be a member of class X or a base c! e 4 
class X, or be a global name. The declaration of a local name eet era a 
the same name in enclosing blocks, members of the function s class, and g a 
names. The declaration of a member name hides declarations of the same nam 
base classes and global names. : i 
A name that i not qualified in one of the ways described above ate i me A 
a static member function of a class X must be declared in the block in iste of 
Occurs, in an enclosing block, be a static member of class X, or a base c 
class X, or be a global name. Sap 

A AETA name in a function definition (§8.3) is in the pope 9k; a 
outermost block of the function (in particular, it is a local name). A functio sae 
ment name in a function declaration (§8.2.5) that is not a function definition i 
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local scope that disappears immediately after the function declaration. A default 
argument is in the scope determined by the point of declaration (§3.2) of its argu- 
ment, but may not access local variables or nonstatic class members; it is evaluated 
at each point of call (§8.2.6). 


B The scope of arguments in a function declaration that is not also a function defini- 
tion is useful only for catching errors. For example, 


extern int f( 

int a, 

int b =a // error: local variable in argument list 
Me 


See §8.2.5. D 


A ctor-initializer (§12.6.2) is evaluated in the scope of the outermost block of 
the constructor it is specified for. In particular, it can refer to the constructor’s 
argument names. 


m Note however, that the base class and member names are looked up in the scope 
of the class itself. 


class X { 
int a; 
public: 
X(int); 
Is 


X::X(int a) :a(a) {) // perverse, but legal 








Commentary 


The rest of this chapter discusses techniques for implementing inheritance. The 
emphasis is on the run-time mechanisms provided by the compiler. 
10.1c Single Inheritance 


An object of a class is typically represented by a contiguous region of memory. 
Consider a simple class A declared as follows: 
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class A { 
Public: 

int a; 

void f(int i); 
)? 


An object of class A will look like this: 


int a; 


No information is stored in an A except the integer a specified by the user; in par- 
ticular, no information about the member function f () is stored in the object. 

Objects of derived classes are composed by concatenating the members of the 
base classes and of the derived class itself. Given these declarations, 


class A { 
int a; 
void f(int); 


class B : public A { 
int b; 
void g(int); 

}; 


class C : public B { 
int cC} 
void h(int); 

}; 


an implementation of an object of class C may look like this: 





This is the normal layout used by most implementations, but because CH does not 
guarantee the order in which storage is allocated for derived classes, a C object 
could plausibly be laid out as follows: 
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A more complicated representation of a class stores, for each class declared, a 
table of offsets of class members; a pointer to a class object includes a pointer to 
the offset table and a pointer to an instance of a class object. So given the class 
declarations above and a pointer 


C* cptr=new C; 


the layout in memory would look like this: 


cptr: 





> mn 
| offset ofa | 

| offset of b | 
e R 
offsetofc | 


N 


| int a; 
| int b; | 


int-e? 


This scheme can benefit projects developing or maintaining large applications. If a 
class member’s entry in the offset table is guaranteed not to change as long as that 
member exists and its type is not changed, code that accesses the member through 
the class offset table need not be recompiled, even though other members have 
been added to or deleted from the class declaration. Thus recompilation and relink- 
ing can be faster than when the normal class layout is used. The disadvantage is 
that because every access to a class object involves indirection, the generated code 
will be both larger and slower. 

For the rest of this chapter, we will consider only the normal layout of class 
objects. 


10.2c Multiple Inheritance 
Given two classes 


class A { /* ... */ af(int); }> 
class B { /* ... */ bf(int); }; 
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a third can be declared using both as base classes, as follows: 
class C : public A, public B { /* ... */ }; 


An object of class C can be laid out as a contiguous object like this: 





As with single inheritance, there is no guarantee about the order in which storage is 


allocated for base classes (§10.1), so alternatively a C object might be laid out as 
follows: 





Accessing a member of class A, B, or C is handled exactly as in single inheri- 
tance: the compiler knows the location in the object of each member and generates 
the appropriate code (without indirection or other unnecessary overhead). 

If the object is laid out with class A first, followed by B and then C, calling a 
member function of A or C is the same as calling a member function with single 
inheritance. Calling a member function of B given a pointer to a C object is 
slightly more complicated. Consider 


C* pe = new C; 
pc->bf (2); // assume C has no other member called bf 


Naturally, B: :bf () expects a pointer to a B object as its this pointer. To get a 
pointer to the B part of the containing C object, the offset of a B in a C, a compile- 
time constant we’ll call ‘‘delta(B),’’ must be added to pc. The compiler 
transforms the call to the equivalent of 
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((B*) ((char*) pctdelta(B)))->bf (2); 


The relationship of pc and the this pointer passed to B: : bf are shown below. 


delta (B) 


B::bf’s this —> 





10.3c Multiple Inheritance and Casting 


With multiple inheritance, casting may change the value of a pointer. Given the 
declarations 


class A { fa era 87 I 
clases B { /* vae A }; 
class © : public A , public’ B { /* ... 4/5}; 


C* pe = new C; 
B* pb; 


casting pc to a B*, either implicitly or explicitly, as in either of the following: 


pb = pe; 
pb = (B*) pc; 


must be translated by the compiler to the equivalent of 
pb = (B*) ((char*)pctdelta(B)); 


Here, the offset of the B part in a C object, delta (B), is be added to pc (just as 
when the this pointer is computed for a member function of B given a pointer to 
a C object, which is an implicit cast). Similarly, casting pb to a pointer to a C 
(which must be explicit — see §10.4). For example, 

pe = (C*) pb; 
is translated to 

pe = (C*) ((char*)pb-delta(B)); 


Thus casting yields a pointer referring to the appropriate part of the object. In this 
example, pe will point to a C object, and pb will point to the B part of the same C 
object, as shown below. 
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pc —~> 
delta (B) 


pb —> 





Comparison of pointers is treated similarly. The expression 
(pc == pb) 
is interpreted as 
((B*) pe == pb) 


(It is not treated as pc==(C*)pb since there is a standard conversion from a 
derived class to its base, but not a standard conversion from a base class to its 
derived class; see §10.4.) The generated code for the comparison will be 
equivalent to 


( (B*) ((char*)pctdelta(B)) == pb ) 


Casting a value to a pointer to a base class and then to some other type may not 
yield the same result as casting directly to the second type. That is, for some class 
B and a pointer p to a class C derived from B, (char*) (B*)p != (char*)p. 


(char*) p ————> 
delta (B) 


(char*) (B*) p—> 





When B is a base class of C and p is a C*, however, the following relationships are 


guaranteed: 
(C*)p ==p 
(B*)p ==p 


(B*)p == (C*)p 
There is precedent in both C and CH for the casting operation to produce onè 
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value given another, and not simply to reinterpret a bit pattem. For example, 
(float) (int) 1.2 is not equal to 1.2. C implementations for machines on 
which pointers to character have a different representation from pointers to other 
data provides another example. On such machines casting to and from character 
pointers often involves producing a value with a bit pattern that differs from that of 
the original pointer. 

This is not the whole story, however. Consider a pointer with the value zero. 


C* pe = 0; 
B* pb = 0; 
if (pb == 
pb = pc; 

if (pb == 0) { /* do something */ } 


0) { /* do something */ ) 


According to the discussion above, the assignment of pc to pb will be interpreted 
as 


pb = (B*) (({char*)pct+delta(B)); 
and the second comparison will fail because pb will have the value (B*) 


((char*)0+delta(B)). In casting, therefore, an implementation must treat a 
pointer with the value zero as a special case. To handle the assignment 


pb = pe; 
correctly, the code generated must do the equivalent of 


pb = (pce==0) ? 0: (B*) ((char*)pc+delta(B)); 


10.4c Multiple Inheritance and Implicit Conversion 


A pointer to a derived class may be implicitly converted to a pointer to a base 
class, but a pointer to a base class may not be implicitly converted to point to a 
derived class (§10). To see why this must be so, consider the following (explicit 
conversions are used here to illustrate): 


class Alg L5 ae EAs 
class B 1 7/2. tA 
class C's public’ A; public Bi (G/S anar] 


C* pe = new C; 
B* pb = (B*)pc; // OK; pb points to B part of C 


The result looks like this: 
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pe ———____> 


pb= (B*) pc —> 





Because an object of a derived class always contains a sub-object of its base 
class, the conversion of a pointer to the derived class to point to the base class 
object within the derived class object to which it points is legal. Any given object 
of a class that is a base class for another class, however, is not necessarily part of 
an object of that derived class. The following code, were it legal, would lead to 
trouble: 


B* pb 
CIDE 


new B; 
(C*) pb; // error: where does pc point? 


The result looks like this: 


pc=(C*) pb —> 
??? 


pb ———_—_—__> 


B object 


Any use of pc will most likely produce a runtime error. Few implementations 
check for bad casts like this, but it would be legal for a compiler to report such an 
error. 

Because a pointer to a derived class can be implicitly converted to a pointer to 
its base class, the use of a pointer to a derived class and a pointer to a base class 
for that derived class in the same expression is legal. 
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struct A {}; 
struct B: A (J; 
SCruce, Gest At) 


void f(int i, A* pa, B* pb, C* pc) 


{ 
i ? pa i phy // ok 
i ? pb: 3; pa; // ok 
i. ? pb e pe; // error 


} 


An effect of there being no implicit conversion from a base class to its derived 
class is that the use in a single expression of pointers to two classes independently 
derived from a common base class will be an error (unless an explicit conversion 
function has been supplied). Here, pa and pc are pointers to two different types; 
their use in the same expression is a type mismatch. 


10.5c Virtual Base Classes 


Suppose we have an inheritance hierarchy similar to the A, B, C, L example in 
§10.1, except that only one object of the base class L is required in a C object. 
Then L could be declared a virtual base class, as follows: 


class D (Lr oes Sass 

class A : public virtual D { /* ... */ }; 
class B : public virtual L { /* ... */ J; 
class C : public A, public B { /* ... */ }; 


Each A object or B object will contain an L, but only one object of class L will 
exist in a C object. Clearly the object representing the virtual base class L cannot 
be in the same position relative to both A and B in all objects. Therefore a pointer 
to L must be stored in all objects of classes that have L as a virtual base. An 
implementation of A, B, and C objects will look something like this: 


A* aptr = new A; 


B* bptr = new B; 
C* cptr = new C; 


aptr ——> 





J 
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bpt r ——> 


cptr ——> 


Chapter 10 





The virtualness of L in A, B, and C is a property of the derivation, and not a 
property of L itself. 

Except that it results in a unique object in its derived classes, a virtual base 
class behaves the same way a nonvirtual base class does. Every virtual base of a 
given class type in an inheritance structure refers to the same object, 

A class may be both an ordinary and a virtual base in the same inheritance 
structure. Given these declarations, 


class 
class 
class 
class 
class 
class 


L 
A 
B 
C 
D 
E 


{ 


fab ese poh ARS 
public virtual L { /* ... */ }; 


: public virtual L { /* .../*/ }; 
tepublic-A, public Bl [isc ws pe 
SepUDIZC Ebr l/ Fs «2 Az 

Sepublic D, public C [Z4 m 37. h 


an E object will contain two L objects, one virtual and one nonvirtual. An imple- 
mentation of an E object will look something like this: 


Section 10.5c Virtual Base Classes 227 








10.6c Virtual Base Classes and Casting 


One can cast from a derived class to a virtual base class. The generated code will 
use the pointer to the virtual base stored in the derived class (shown in the 
diagrams in §10.5 above). 

Casting from a virtual base class to a derived class is disallowed to avoid 
requiring an implementation to maintain pointers to enclosing objects. 


10.7c Single Inheritance and Virtual Functions 


Virtual functions can be implemented with a table of pointers to virtual functions, 
the vtbl. With single inheritance, a class’s vtbl will point to the appropriate 
functions, and every object of that class will contain a pointer to the vtbl. 

Given the following declarations: 


class A { 
public: 
int a; 
virtual void f(int); 
virtual void g(int); 
virtual void h(int); 
}; 
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class B : public A { 
public: 

int b; 

void g(int); 
Sy 


class C : public B { 
Public: 

inte? 

void hfint); 
}; 


a class C object will look something like this: 





A call to a virtual function is transformed by the compiler into an indirect call. 
For example, 


C* pc=new C; 
pe->g (2); 


becomes something like 
(* (pe->vptr[1])) (pc, 2); 


Implementing virtual functions with multiple inheritance will require multiple 
vtbls (§10.8), but notice that for a class derived through a single inheritance 
chain, there will be a single instance of each virtual function to which any call will 
resolve, whether the function is called through a pointer to an object of the derived 
class or through a pointer to any of its base classes. Thus there is a single set of 
functions associated with a derived class, which can be stored in a single vt bl. 


10.8c Multiple Inheritance and Virtual Functions 


With multiple inheritance, implementing virtual functions is slightly more compli- 
cated. Consider the following declarations: 


class A { 
public: 

virtual void f{); 
i; 
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class B { 
public: 
virtual void f(); 
virtual void g(); 
iz 


class C : public A, public B { 
Public: 

void f(); 
My 


Because class C is derived from class A and from class B, the following calls 
will all invoke C: : f (): 
pa->f(); 


pb->f(); 
pe->f(); 


On entry to C::f, the this pointer must point to the beginning of the C 
object, and not to the B part (this discussion assumes that a class object is laid out 
in memory as shown above (§10.2); note that the A part coincides with the begin- 
ning of a C object). It cannot always be known at compile time, however, that the 
B pointed to by pb is part of a C, so the offset of a B object within a C object, 
delta (B), is not a constant at compile time. Consequently delta (B) must be 
stored where it can be found at run time. Because the offset is used only for cal- 
ling a virtual function, the logical place to store it is in the virtual function table. 

A plausible implementation for a vtbl entry would be 


struct vtbl_ entry { 
void (*fct) (); 
int delta; 

}; 


Using an int as the type of the offset will limit the size of an object, but on most 
machines an int will be large enough to hold the offset for any reasonably sized 
object. A third member may be added to a vtbl entry to support pointers to 
members using the same layout for both vt bl entries and pointers to members for 
uniformity; see §8.1.2, 

The this pointer to be passed to a virtual function can be computed by sub- 
tracting the offset of the object for which the virtual function was defined from the 
offset of the object used to invoke the function, then subtracting this difference 
from the pointer used in the call (for a more complicated example, see §10.10). 
Here, the value of delta(B) will be needed to find the beginning of an object 
containing a B, in this case a C, given a pointer to a B. The generated code will 
subtract the value of delta (B) from the value of the pointer, so the negative of 
the offset, -delta (B), is stored. An object of class C, then, will look something 
like this: 
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A & C’s vtbl: 
EC ls few 0 


delta (B) Sein Ea A E 


pb —> 


orn BUS vtbl: 
&6C::£ ' -delta(B) 


&B::g 0 





The vtbl for B in C is different from the vtbl of a separately allocated B. 
Each combination of base class and derived class has its own vtbl. In general, an 
object of a derived class needs a vt bl for each base class plus one for the derived 
class except that a derived class can share a vt bl with its first base class. Thus in 
the example above only two vtbls are used for an object of type C (one for an A 
in a C shared with the table for a C object, plus one for a B object in a C). 

The call 


pb->f(); 


in the example above invokes C: :f, having been transformed by the compiler to 
something like this: 


register vtbl_entry* vt = &pb->vtbl [index (f)]; 
(*vt->fct) ((B*) ((char*) pb+vt—>delta) ); 


An alternative implementation avoids storing the delta for the this pointer in 
the virtual function table. Instead, a pointer to code to be executed is stored. 
When no adjustment to this is needed, the pointer in the vtb1 points to the 
instance of the virtual function to be executed; when this must be adjusted, the 
pointer in the vtbl points to code that adjusts the pointer then executes the 
appropriate instance of the virtual function. The class C, declared above, would be 
represented in this scheme as follows: 
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delta (B) 
y 


poc 





This scheme allows more compact virtual function tables and potentially faster 
calls to virtual functions. The drawback of such a scheme is that it is less portable. 

The code that adjusts the this pointer is usually called a thunk. This name 
goes back at least as far as the early implementations of Algol60, where such small 
pieces of code were used to implement call-by-value. 


10.8.lc Virtual Function Tables 


In some 0 C+ implementations, the code for a virtual function table is duplicated 
in the object file produced for each CH source file that declares or includes 
declarations of the class containing the virtual functions. 

Consider a header file containing the following: 


class A { 
public: 
virtual void f(); 


J}; 


class B { 

public: 
virtual void f(); 
virtual void g(); 


}; 
class C: public A, public B { 
public: 
void f(); 
}; 


Now suppose that these declarations are included in multiple CH source files, 
Each time a naive compiler processes these declarations, even if it knows the 
declarations came from a header file, it will not know whether the virtual function 
tables have already been generated in a separate compilation. Therefore, it must 
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generate the tables. Because most linkers will report an error if an identifier is 
defined more than once, virtual function tables must have unique names. Unique 
names can be created by including the name of the source file in the name of a 
table. The declarations above, when included in the files windows.c, debug.c, 
and interface.c, might yield tables named as follows (name encoding is dis- 
cussed in §7.2.1): 


_vtbl__1A__windows_c 
_vtbl__1B_ _windows_c 
__vtbl__1A__debug_c 
_vtbl__1B__debug_c 
CERVISIA ls interface ¢ 
__vtbl__1B__interface_c 


(There are no tables for C objects because C shares A's virtual function table.) 

The obvious drawback of this implementation is that the tables generated for 
each translation unit after the first duplicate the contents of the tables generated for 
the first translation unit. For a program with many virtual functions declared in 
many translation units, this duplication may significantly increase the size of the 
generated code. 

Smarter compilers eliminate most of this duplication, producing more compact 
code, by identifying a unique translation unit for which a given vtbl will be gen- 
erated. One reasonable heuristic used is to select the translation unit containing the 
definition of the (lexically) first nonvirtual member function (if there is one) as the 
translation unit for which a class's vtbl will be laid down (obviously, the file 
name will not be included in the vtbl name). Under this scheme, duplicate 
vtbl’s will generated for classes having no nonvirtual member functions, 


10.9¢ Instantiation of Virtual Functions 


Because constructors for base classes are called before the constructor for the 
derived class, an object of a derived class and its environment, including its virtual 
function table (§10.7 and §10.8), is built from the bottom up. Thus a virtual func- 
tion defined in a derived class cannot be invoked for an object of that class until 
the object has been constructed. Consider the following example: 


class A { 

public: 
virtual void f() { printf("A::f() called"); } 
A() { } 


. 
, 
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i class B : public A { 


public: 
B() ({ £0); } // call virtual f() 
void g() { £(); } // call virtual f() 
})e 
class C : public B { 
public: 
void f() { printf("C::f{) called"); } 
C() { } 
J}; 
main () 
{ 
Ger // will produce "A::f() called” 


cig () 2 // will produce "C::f() called” 
) 


When B::B() is executing, the C part of the object being constructed exists 
only as raw storage and cannot be accessed through a virtual function. The avail- 
able £() is A::£(). The first point at which C::f£() can be called as f () is 
the first statement in the constructor C: :C (). 


10.10c Virtual Base Classes with Virtual Functions 


Building the tables for virtual function calls gets more complicated when virtual 
base classes are used. Consider the following declarations: 


class W { 

public: 
virtual void f(); 
virtual void g(); 
virtual void h(); 
virtual void k(); 
Whe ae 

Me 


class MW : public virtual W { 
public: 

void g(); 

ILE ee 


}; 


class BW : public virtual W { 
public: 

void f(); 

IOP He 
}; 
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class BMW : public BW , public MW, public virtual W { 


public: 
void h(); 
He fs 

ye 


The inheritance relationship for this example can be shown in a directed acyclic 
graph (arrows point from derived classes to their base classes) as follows: 


W{£, g, h, k } 


BW { f) MW {g} 
x A 
AR og 
BMW { h} 


The member functions for BMW can be used like this: 


void g(BMW* pbmw) 

{ 
pbmw->f(); // invokes BW::f() 
pbmw->g(); // invokes MW::g() 
pbmw->h(); // invokes BMW::h() 

} 


Now consider the following invocation of the virtual function f (): 


void h(BMW* pbmw) 
{ 
MW* pmw = pbmw; 


pmw->f (); // invokes BW::f()! 
} 


A call to a virtual function through one path in an inheritance structure may result 
in the invocation of a function redefined on another path. This is an elegant way 
for a base class to act as a means of communication between sibling classes, such 
as BW and MW above. Suppose class W represents windows, class BW represents 
windows with borders, class MW represents windows with associated menus, and 
class BMW represents windows with associated menus and borders. 

Sometimes a menu needs to know where the inside its containing window is so 
that it can determine where it may be displayed. Now suppose the virtual function 
f() retums the boundaries of the inside a window. The menu will need the 
instance of £() provided by BW, the border class, not the instance provided by W, 


biic 
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the window class — or else the menu could be displayed so that it overwrote part of 
the border. In some window systems that is undesirable. 

If the base class W had a virtual function £ () that was redefined in both MW and 
BW but not in BMW, an ambiguity would exist. A compiler can detect such ambi- 
guities when it builds a derived class’s table of virtual functions. To avoid ambigu- 
ous function definitions, all redefinitions of a virtual function from a virtual base 
class must occur on a single path through the inheritance structure. 

The layout of a BMW object and its vtbls might look like this: 


MW & BMW’s vtbl: 
PF 
&BW::f ! 0 



















&W::k delta (W) —delta (BW) 


! 

&MW: :g 0 -delta (BW) 
&BMW: :h i 0 
&W::k - 0 -delta (W) 

BW’s vtbl: 

EEEE TT > 

SBWisf | 0 
&MW::g 0 -delta (BW) 
&BMW::h , 0 -delta (BW) 





W's vtbl: 


delta (BW) -delta (W) 
0 -delta (W) 
0 -delta (W) 

0 





|] 
I 
! 
1 
1 
I 
1 





A vinual function must be passed a this pointer to an object of the class for 
which the function was defined. Thus, an offset will be stored with each function 
pointer in a vtbl. When an object is laid out in memory as shown above, the 
offset stored with the virtual function pointer can be computed by subtracting the 
offset of the class for which the vtbl was constructed from the offset of the class 
supplying the function. Here is an example: 


void callvirt (W* pw) 


pw->f(); 
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main() 
{ 
callvirt (new BMW); 


) 


In main, callvirt () is called with a pointer to a BMW, which must be con- 
verted to a W pointer because callvirt expects a W* argument. So when 
callvirt calls £() (through a BMW pointer converted to a W pointer), W's vtb1 
will be used; W's vtb1 indicates that BW: : f () is the instance of the virtual func- 
tion £() to be invoked. To pass BW::f() a this pointer to a BW, the pointer 
pw will have to be cast back to a BMW pointer (by subtracting the offset of W) and 
then converted to a BW pointer (by adding the offset of BW in a BMW object). The 
value of the offset of a BW in a BMW object minus the offset of a Win a BMW is the 
offset stored with the entry for BW: : f () in W's vtbl. 


10.11le Renaming 


Merging two class hierarchies by using them as bases classes for a common derived 
class can cause a practical problem where the same name is used in both hierar- 
chies, but where it refers to different operations in the different hierarchies. For 
example, 


class Lottery { 
YS ive eke 
virtual int draw(); 


}? 


class GraphicalObject { 
TSAR 
virtual void draw(); 


l; 


class LotterySimulation 
: public Lottery , 
public GraphicalObject { 
VRE 

}; 


In LotterySimulation we would like to override both Lottery: :draw () 
and GraphicalObject::draw(), but with two distinct functions, since 
draw() has completely different meanings in the two base classes. We would 
also like LotterySimulation to have distinct, unambiguous names for the 
inherited functions Lottery::draw() and GraphicalObject::draw(). 
The semantics of this concept are simple, and the implementation is trivial; the 
problem seems to be to find a suitable syntax. The following has been suggested: 
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class LotterySimulation 

: public Lottery , 

public Graphicalobject { 

VE PEE 

virtual int l draw() = Lottery: :draw(); 

virtual void go _draw() = GraphicalObject::draw(); 
}; 


This would extend the pure virtual syntax in a natural manner. It could be con- 
sidered a weakness that the notation applies only to virtual functions. Altema- 
tively, this can be considered the real beauty of the scheme. The == operator is a 
plausible alternative to = for expressing renaming. 

Since overloaded functions are obvious candidates for renaming, the complete 
type of the function to be renamed would have to be mentioned, and that type 
would have to match exactly the type of the function being renamed. 

After being renamed, a virtual function from a base class could no longer be 
overridden except by its new name, and any use of the old name would have to be 
qualified by its class name to avoid ambiguity. 


Se 

















Member Access Control 


This chapter explains mechanisms for control of access to class members. 
Access control is based on the use of the keywords public, private, and 
protected to control access to individual members of a class and on the use 
of private and public specifiers to control whether a derived class is con- 
sidered a subtype of a base class or not. The friend mechanism provides a 
way of granting individual functions and classes access to members of a class. 


Access control applies uniformly to function members, data members, member 
constants, and nested types. 


11 Member Access Control 


A member of a class can be 


private; that is, its name can be used only by member functions and 
friends of the class in which it is declared. 


protected; that is, its name can be used only by member functions and 
friends of the class in which it is declared and by member functions and 
friends of classes derived from this class (see §11.5). 


public; that is, its name can be used by any function. 


m The C+ access control mechanisms provide protection against accident — not 
against fraud. Any programming language that supports access to raw memory will 
leave data open to deliberate tampering in ways that violate the explicit type rules 
specified for a given data item. For example, a pointer to a foo can be explicitly 
converted to a pointer to a bar, after which any guarantees provided by the type 
system for objects of type foo can be violated. Furthermore, a programming 
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environment that lets a programmer update any part of a program will leave data 
open to arbitrary access. For example, the definition of class foo can be edited to 
make its representation public, after which arbitrary operations can be applied to the 
representation of a foo, again violating any guarantees provided by the type system 
for objects of type foo. 

These possibilities are considered problems of the management of programming 
and of programming environments and not language problems. 

Another point to note is that it is access to members that is controlled, not their 
visibility. For example, 


int i; 


class X { 
private: 
int i; 


ie 


class Y : public X i 
void £() { itt; } // error: X::i is private 
}; 


Here, the i incremented is X::i, and the access is an error because X::i is 
private. Had i been invisible instead of simply inaccessible, the global i would 
have been updated. 

The reason access control rather than visibility control was chosen was to ensure 
that changes in access status would not quietly change the meaning of a program. It 
was felt that better error messages and fewer obscure errors would result from this 
approach. On the other hand, this decision clearly makes more work for program- 
mers using multiple inheritance by increasing the frequency of name clashes thal 
must be manually resolved. O 


m Note that access control is applied uniformly to all names. For example, 


class X { 

private: 
enum El f al, bl }; 
int il; 
void f1(); 

public: 
enum E2 { a2, b2 }; 
int i2; 
void f£2(); 

ye 


void h(X* p) 
{ 


X::E2 e2 = X::a2; // ok: E2 is public 
int x2 = X;:a2; // ok: a2 is public 
p->i2 = 2; // ok: i2 is public 
Pp->£2(); // ok: £2 is public 
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X::E1 el = X::al; // error: 


int xl = X::al; // error: 
p->il = 1; // error: 
p->f1(); // error: 


(m) 


El is private 
al is private 
il is private 
fl is private 


Members of a class declared with the keyword class are private by 
default. Members of a class declared with the keywords struct or union are 


public by default. For example, 


class X ({ 


int a; // X::a is private by default 


}; 


struct S$ { 


int a; // S::a is public by default 


}; 


11.1 Access Specifiers 


Member declarations may be labeled by an access-specifier (§10): 


access-specifier : member-list,,, 


An access-specifier specifies the access rules for members following it until the end 
of the class or until another access-specifier is encountered. For example, 


class X { 


int a; // X::a is private by default: ‘class’ used 


public: 
int b; // X::b is public 
int c; //-X:3:c is public 
}; 


Any number of access specifiers is allowed and no particular order is required. For 


example, 


struct S { 


int a; // S::a is public by default: ‘struct’ used 


protected: 

int b; // S::b is protected 
private: 

int c; // S::c is private 
public: 

int d; // S::d is public 
}; 


The order of allocation of data members with separate access-specifier labels is 


implementation dependent (§9.2). 
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m For example, the members of this class 


class X { 

int a,b,c; 
protected: 

int d,e,f; 
Public: 

int g,h,i; 
private: 

Inti}, Kas 
i: 


might be allocated in the order they appear 


struct X1 { 
int a,b,c; 
int d,e,f; 
int g,h,i; 
int j,k,1s 
}; 
Another reasonable layout would be 


struct X2 { 
int g,h,i; // public members 
int d,e,f; // protected members 
int a,b,c; // private members 
int j,k,1; // private members 
Me 
Placing the public members first and the private members last has the advantage for 
implementations that pursue a strategy of minimal recompilation after a change to a 
program. If a user changes the private data for a class but leaves its public interface 
unchanged then previously compiled code that uses only public data need not be 
recompiled. Typically, it makes more sense simply not to use public data. Protected 
data, however, is not uncommon. 
The requirement (§9.2) that members not separated by access specifier labels be 
allocated in the order in which they are declared provides compatibility with existing 
C code. O 


11.2 Access Specifiers for Base Classes 


If a class is declared to be a base class (§10) for another class using the public 
access specifier, the public members of the base class are public members of 
the derived class and protected members of the base class are protected 
members of the derived class. If a class is declared to be a base class for another 
class using the private access specifier, the public and protected members 
of the base class are private members of the derived class. Private members of 
a base class remain inaccessible even to derived classes unless friend declara- 
tions within the base class declaration are used to grant access explicitly. 

In the absence of an access-specifier for a base class, public is assumed when 
the derived class is declared struct and private is assumed when the class 1S 


4 
a | 
5 
$ 





Section 11.2 Access Specifiers for Base Classes 243 


declared class. For example, 


class B { /* ... */ }; 

class Dl : private B { /* ... */ }; 

class D2 : public B { /* ... */ }; 

class D3 : B { /* ... */ }3 // `B’ private by default 
struct D4 : public B { /* ... */ }; 

struct D5 : private B { /* ... */ }; 

etruct. D6 B (Aa 1.0 aA } // `B' public by default 


Here B is a public base of D2, D4, and D6, and a private base of D1, D3, and D5. 


@ Jn the absence of an access specifier, a base class is private; in the absence of a 
virtual specifier, it is nonvirtual. Explicitly using the keyword private is 
recommended for declaring private base classes because the compiler messages 
caused by accidental use of private base classes can be most confusing. For exam- 
ple, novices often don't know about access specifiers and get confused by this: 


class X { public: f(); }; 


class ¥ = X% 4 Je // no access specifier 
// private by default 


void g(Y* p) 
d 
p->f(); // error 


} 


Even experts can get caught. A compiler can be most helpful by issuing a warning 
for the missing access specifier. 

Having private as the default was chosen to reflect the general view that 
things that are not explicitly declared public are private. Defining a default access 
specifier was probably a mistake. 

An access specifier or virtual specifier applies only to the base class immedi- 
ately following it. Thus, for example, 


Class Ds. public virtual A,B, Cif /* 3.8735 


declares D to have a public virtual base A, and private nonvirtual bases B and C. O 


Specifying a base class private does not affect access to static members of the 
base class. If, however, an object or a pointer requiring conversion is used to 
select the static member the usual rules for pointer conversions apply. 


@ This can cause an attempt to use a static member of a private base class to fail just 
as an attempt to use a nonstatic member would. 


class B { 

public: 
static void f(); 
void g(); 

}; 


class D : private B { }; 
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class DD : public D { 


void h(); 

Me 

void DD::h() 

{ 
BESLI? // ok 
this->f(); // error: cannot convert ‘this’ to a B* 
this->B::f(); // error: cannot convert ‘this’ to a B* 
fi); // error: cannot convert ‘this’ to a Bt 
gü); // error: cannot convert ‘this’ to a B* 


) 


Had the call of B::£() in DD::h() not been allowed, we would have the absur- 
dity of a member function having less access than a global function. 


void k() 
{ 

B::f(); 4/ ok 
) 


Members and friends of a class X can implicitly convert an X* to a pointer to a 
private immediate base class of X. 


m For example, 


class B { }; 
class D : private B { 
public: 


friend B* f(D* p) { return p; } 
B* mem() ( return this; } 
J; 


B* g(D* p) 
{ 


return p; // error: B is a private base of D 


) 


11.3 Access Declarations 


The access to a member of a base class in a derived class can be adjusted by men- 
tioning its qualified-name in the public or protected part of a derived class 
declaration. Such mention is called an access declaration. 

For example, 
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class B ({ 
int a; 
public: 
Intub, C? 
int bf(); 
); 


class D : private B { 
int d; 
public: 
B::c; // adjust access to ‘B::c’ 
int e; 
int df(); 
}; 


int ef(D&); 


The extemal function ef can use only the names c, e, and df. Being a member 
of D, the function df can use the names b, c, bf, d, e, and df, but not a. Being 
a member of B, the function bf can use the members a, b, c, and bf. 


m Note that no type can be specified when adjusting the access of the name. For 


example, 
Class BAAS osc) AZE 
class D : private B { 
int d; 
public: 
int B::c; // error:qualifier in member declaration 
// or type in access declaration 
3 
(m) 


An access declaration may not be used to restrict access to a member that is 
accessible in the base class, nor may it be used to enable access to a member that 
is not accessible in the base class. For example, 


class B { 
public: 
int a; 
private: 
int b; 
protected: 
int c; 


}; 


ee eo 
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class D : private B { 
public: 
B::a; // make ‘a’ a public member of D 
B::b; // error: attempt to grant access 
// can't make ‘b’ a public member of D 
protected: 
B::c; // make `c’ a protected member of D 
B::a; // error: attempt to reduce access 
// can't make ‘a’ a protected member of D 
}; 


m Allowing the writer of the derived class to increase access would enable a pro- 
grammer to violate the guarantee that only the members and friends listed in the 
class declaration can access the private members. 

Allowing downward adjustments of accessibility of base class members in 
derived classes would give a more convenient notation when one wants to provide 
all but a few of the public members of a base class as public members of the derived 
class. It would also complicate the rules, however, for what is a public base class. 

Suppose, for the moment, that C+ did allow this declaration: 


class DD : public B ( 
private: 

Bia; // error 
J}; 


Now, even though DD is publicly derived from B, it would not have B as a public 
base class. The reason is that the access to members of B through a pointer to a DD 
object differs from the access to the members of B through a pointer to a B object. 
In particular, the standard conversion of a DD* to a B* would grant a user access to 
B::a even though it had been explicitly declared private for a DD. Conse- 
quently, B could not be considered a public base class of DD. Any functionality or 
expressive power that might be added to the language by allowing downward adjust- 
ments of accessibility would not offset users’ confusion about what constituted a 
public base class and the added complication in the definition and implementation of 
the language. O 


An access declaration for the name of an overloaded function adjusts the access to 
all functions of that name in the base class. For example, 


class X { 
public: 
£(); 
f (int); 
}; 


class Y : private X { 
public: 

X::f; // makes X::f() and X::f(int) public in Y 
}3 
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m These rules imply that it is not possible to adjust access to overloaded functions 
that do not have the same access. 


class X f 

private: - 
ff(int); 

public: 
£l)? 

}; 


class Y : private X { 
public: 


X: f; // error 
}; 


The access to a base class member cannot be adjusted in a derived class that 
also defines a member of that name. For example, 


class X { 
public: 

void f(); 
Js 


class Y : private X { 
public: 

void f (int); 

X::f; // error: two declarations of f 
}; 


m One could imagine a powerful language extension that allowed the previous exam- 
ple by letting an adjustment of access act as a way of overloading functions so that 
the declaration of Y would have been equivalent to 


class Y : private X ( 
public: 

void f(int); 

void f() { X::f(); } 
Mr 


This would have implications, however, for type checking. In the previous example 
X::£() is a member of X and is applied to an object through an X* pointer. When 
a pointer of type Y* is used to call X::£ the pointer suffers a standard conversion. 
Had the access adjustment been considered to redefine f in the scope of Y this 
would not have been the case. It is possible to construct examples using overloaded 
operators where this change in interpretation would be significant. O 


ee 
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11.4 Friends 


A friend of a class is a function that is not a member of the class but is permitted 
to use the private and protected member names from the class. The name of a 
friend is not in the scope of the class, and the friend is not called with the member 
access operators (§5.2.4) unless it is a member of another class. The following 
example illustrates the differences between members and friends: 


class X { 

int a; 

friend void friend_set(X*, int); 
public: 

void member set (int); 
}; 


void friend set(X* p, int i) { p->a = i; } 
void X::member_set (int i) { a = i; ) 


void f() 

( 
X obj; 
friend _set (&0bj,10); 
obj.member_set (10); 


m Note that a friend is as much a part of the interface of a class as a member is. 
Since a friend declaration has to appear in the declaration of the class of which it is 
a friend, no violation of the protection mechanisms is implied. Friendship, like all 
other access, is granted by the class — not unilaterally grabbed by the friend. 

The friend mechanism is important in two ways. First, a function can be a 
friend of two classes. For example, 


class Vector; 


class Matrix { 
friend Vector operator+(const Matrixs, const Vectors); 
}; 


class Vector { 
friend Vector operator+(const Matrix&, const Vectors); 
ye 


This can lead to increased efficiency by letting a friend function bypass unsuitable 
access functions provided to general users. Alternatively, the use of friends can lead 
to cleaner interfaces by avoiding complicating the interfaces of both classes with 
member functions specifically designed to serve what would otherwise have been 4 
global function with no special access to the representation of the classes. 

Second, a friend function allows uset-defined conversions to be used for its first 
argument, where member functions do not. This allows programmers to express the 
notion that an Ivalue is required by an operation by making that operation a member 
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and, conversely, to express the notion that an lvalue is not required by making that 
operation a friend. For example, 


class complex { 

TPs sae 

complex operator+=(complex); 

friend complex operator+ (complex, complex); 
Me 


Here the member complex: :operator+= requires a complex Ivalue as its first 
argument, so 1+=z is an error when z is a complex number. On the other hand, the 
friend operator+ (complex, complex) will accept any value that is a complex 
number or can be converted into one, so 1+z is ok. 

In addition, some programmers prefer the usual function call notation supported 
by friend functions to the member call notation required for member functions, 
Often such preferences have a rational bias. Consider a matrix inversion routine; 
there are two choices. 


m.invert (); // one preference 
invert (m); // another preference 


We would expect m. invert () to invert mand invert (m) to leave m unchanged 
and retum a new matrix that is the inverse of m so the usage would be 


M.invert (); // one preference 
m2 = invert(m); // another preference 


Note that a virtual function must be a member. O 


When a friend declaration refers to an overloaded name or operator, only the 
function specified by the argument types becomes a friend. 


m One could imagine declaring all functions called f friends by a single declaration, 
but doing so would be a bit indiscriminate. It would enable a user to grab access to 
a class simply by declaring a function f with a hitherto unused argument type. O 


A member function of a class X can be a friend of a class Y. For example, 


class Y { 
friend char* X::foo(int); 
// 

)? 


All the functions of a class X can be made friends of a class Y by a single declara- 
tion using an elaborated-type-specifier (§9.1): 


class Y { 
friend class X; 
I AA 

}e 


m Note that only an elaborated-type-specifier and not a complete class declaration is 
allowed in a friend declaration, so this is an error: 
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class Y { 
friend class X { int a; }; // error 
Vdi alee 

); 


m Another use of friends is provide access to the representation of a class to func- 
tions that cannot be member functions because they will be called from another 
language. For example, 


class T; 
extern "C" void interface _function(T*); 


class T { 
a 
friend void interface_function(T*); 


Me 
Naturally, the same effect could be had by defining interface functions to call 


member functions, but that could lead to the doubling of the number of functions 
needed and to a doubling of the function call overhead. O 


Declaring a class to be a friend also implies that private and protected names from 
the class granting friendship can be used in the class receiving it. For example, 


class X { 
enum { a=100 }; 
friend class Y; 


}; 


class Y { 
int v[X::a]; // ok, Y is a friend of X 


-)3 


class Z { 
int v[X::a); // error: X::a is private 


yi 
If a class or a function mentioned as a friend has not been declared its name is 
entered in the same scope as the name of the class containing the friend declaration 


(§9.1). 


tw This implies that a friend declaration may be the first mention of a class or a func- 
tion name. There is no way, however, of declaring a member function earlier than 
its class, 
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class Y; // forward declaration of the name ‘Y’ 


class X { 
friend void Y::f(); // error: Y undefined 
void g(); 

}; 

class Y { 
friend void X::g(); // ok: X defined 
void £(); 


Me 


The only way of specifying mutual friendship between two classes is to declare 
all of the second class a friend of the first. For example, 


class XX { 
friend class YY; // all of YY, 
// including YY:f{), is a friend 
void g(); 
he 
class YY { 
friend void XX::g(); // ok: XX defined 
vöid f£(); 


o 


A function first declared in a friend declaration is equivalent to an extern 
declaration (§3.3, §7.1.1). 


m This implies 


Static void ff) C /* z= A] 
class X { 
friend g(); // implies: extern g(); 
J? 
class Y { 
friend void f(); // ok: £() still has internal linkage 
Me 
Sstatic.g(} ( f* =<... 47%} // error: inconsistent linkage 


Odd maybe, but it follows directly from the linkage rules (§7.1.1), which were the 
strictest ANSI C compatible rules we could find. O 


A friend function defined in a class declaration is inline and the rewriting 
tule specified for member functions (§9.3.2) is applied. A friend function 
defined in a class is in the (lexical) scope of the class in which it is defined. A 
friend function defined outside the class is not. 
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@ For example, 


typedef char* T; 


class X { 
typedef int T; 
friend T LAT) {/* 5... A) A int flant) 
friend T h(T); // int h(int) 

); 

void h(T) { /* e */ } // void h(char*) 


Here, the function called h() declared as a friend of class X is not the function 
called h () defined outside X; their types differ. O 


Friend declarations are not affected by access-specifiers (§9.2). 
Friendship is neither inherited nor transitive. For example, 


class A { 
friend class B; 
int a; 

); 


class B { 
friend class C; 
); 


class C { 
void f(A* p) 
{ 
p->at+; // error: C is not a friend of A 
// despite being a friend of a friend 


}; 


class D : publicB { 
void f(A* p) 
{ 
p->att+; // error: D is not a friend of A 
// despite being derived from a friend 


}; 


@ The rule against inheriting friendship is sometimes not appreciated; that is, it occa- 
Sionally gets in the way of a user. Consider, however, the effect of allowing friend- 
Ship to be inherited, That would make it possible for a user to grab access. Or- 
Using a more imaginative vocabulary — this would become possible: 


Lo. SE per 
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class ReallySecure { 

friend class TrustedUser; 
ET oats 

i; 


class TrustedUser { 
FE i's 
Me 


class Spy : public TrustedUser { 
// aha! 
h; 


The mechanism for allowing a user to grab access (to an explicitly defined interface) 
is protected members. O 


11.5 Protected Member Access 


A friend or a member function of a derived class can access a protected static 
member of a base class. A friend or a member function of a derived class can 
access a protected nonstatic member of one of its base classes only through a 
pointer to, reference to, or object of the derived class (or any class derived from 
that class). For example, 


class B { 
protected: 
int i; 


i 


class Dl : public B { 
)i 


class D2 : public B { 
friend void fr(B*,D1*,D2*) ; 
void mem(B*,D1*); 

}; 


void fr(B* pb, Dl* pl, D2* p2) 
{ 
pb->i = 1; // illegal 
pl->i = 2; // illegal 
p2->i = 3; // ok (access through a D2) 
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void D2::mem(B* pb, D1* pl) 
{ 
pb->i = 1; // illegal 
pl->i = 2; // illegal 
Sch // ok (access through ‘this’) 


void g(B* pb, D1l* pl, D2* p2) 
{ 
pb->i = 1; // illegal 
pl->i = 2; // illegal 
p2->i = 3; // illegal 


m The access specifiers private and public provide a way to distinguish uses of 
the members of a class by the implementer of the class from uses by others, whom 
we might call ‘the general public.’" This mechanism serves the traditional notions 
of data abstraction well. A derived class, however, constitutes a different kind of 
user of a class, and the notions of object-oriented programming relying on derived 
classes are not well served by the simple public/private scheme. 

Without the protected mechanism, the programmer of a class that is intended 
to be used as a base class must often make data public or provide unsafe interface 
functions to serve the needs of the programmers of derived classes. In effect, what 
would have been the protected interface gets exposed to the general public for 
which it most likely is unsuited. An equally unacceptable altemative is to force 
implementers of derived classes — that is, often, the programmers providing the 
implementations for the interface specified by the base class — to use only the res- 
tricted interface intended for the general public. The sharp private/public distinction 
doesn't adequately reflect the reality of programming with class hierarchies. 

Conversely, had only protected been supported, it would have been impossi- 
ble for the programmer of a class to protect data because anyone could come along 
and grab access by deriving a class. This would preclude enforcing meaningful 
interfaces and maintaining the level of data abstraction that allows changing the 
underlying representation of an object. Often, such a change would not be practical 
because too many users had granted themselves access and thus become critically 
dependent on implementation details that would better have been left hidden. 

One way of understanding protected is as a mechanism for the writer of a 
class to give other programmers the right to grant themselves access to a specific 
subset of the representation and operations. O 


m Consider allowing a derived class to access protected members of any object with 
the type of one of its base classes. That is, relax the restriction that access to a pro- 
tected member must be through a pointer to, reference to, or object of the derived 
class. This would allow a class to access the base class part of an unrelated class (as 
if it were its own) without the use of an explicit cast. This would be the only place 
where the language allowed that. 
There are examples where the restriction appears to provide protection against 
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accidents. For example, suppose I am running a bank, and I have many different 
kinds of accounts. I would like to have a base class, Account, that has information 
common to all kinds of accounts, including the account balance, so a friend of 
Account can walk the list of all Accounts and tell me the financial position of 
my bank at any time. Each kind of Account, however, has its own rules for updat- 
ing the balance (for example, what rate of interest is paid, when it is compounded, 
what types of deposits are accepted, special penalties for early withdrawals, and so 
on), so the derived classes which are all the different kinds of accounts contain the 
code for updating the balance. The member functions of checking accounts, 
however, should not be able to access the balance in an AutoLoan_account. 
The restriction prevents that. 

The example that caused the restriction to be introduced was a logically 
equivalent example involving device drivers. A driver for one kind of device 
accidentally updated the information relating to another kind of device, and the sys- 
tem mysteriously crashed. The accidentally updated information was stored in a 
common base class and accessed through a pointer to that base class and not the 
appropriate derived type. Naturally, the use of a virtual function for performing the 
update would have avoided the problem. O 


11.6 Access to Virtual Functions 


The access rules (§11) for a virtual function are determined by its declaration and 
are not affected by the rules for a function that later overrides it. For example, 


class B { 
public: 

virtual f(); 
F; 


class D : public B { 
private: 

f(); 
}; 


void f() 
{ 
D d; 
B* pb 
D* pd 


&d; 
&d; 


pb->f ();. // ok: B::f() is public, 
// D::£() is invoked 
pd->f(); // error: D::f() is private 
} 

Access is checked at the call point using the type of the expression used to denote 
the object for which the member function is called (B* in the example above). The 
access of the member function in the class in which it was defined (D in the exam- 
ple above) is in general not known. 


256 Member Access Control Chapter 11 


m Private virtual functions provide a way for the implementation of a base class to 
rely on derived classes without the functions involved being exposed to the general 
users of the base class. Whether the derived class choses to expose the functions to 
its users is not a concem for the base class writer. O 


11.7 Multiple Access 


If a name can be reached by several paths through a multiple inheritance graph, the 
access is that of the path that gives most access. For example, 


class W { public: void f(); ); 
class A : private virtual W ( }; 
class B : public virtual W { }; 
class C : public A, public B { 

voids () AENEUS rok 
); 


Since W::£() is available to C::£() along the public path through B, access is 
legal. 


m The alternative, granting the least access to the derived class, was considered, but 
rejected as an inconvenience providing at most the illusion of protection. If a 
member of a class is accessible through any path, it is, in fact, accessible; making 
the user go through contoriions to get to it in some but not all cases seemed point- 
less and self-defeating. O 











Commentary 





11.lc General Ideas 


What protection is needed depends critically on what needs to be protected and 
from whom. In other words, there is a wide variety of needs that depend critically 
on the applications being written and the philosophy of the programmers involved 
in the project. 

C+ does not attempt to provide the most detailed control of protection or tO 
provide every conceivable mechanism for expressing every conceivable protection 
need. Doing that would imply a complexity far greater than what is provided, 
which already gives an uncommon degree of expressiveness. 

A few basic principles pervade the system: 

[1] Protection is provided by compile-time mechanisms, against accident, not 

against fraud or explicit violation. 
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[2] Access is granted by a class, not unilaterally taken. 
[3] Access control is done for names and does not depend on the type of what 
is named. 
[4] The unit of protection is the class, not the individual object. 
[5] Access is controlled, not visibility. 
The last two points are explained below. 


11.2c Per Class Protection 


The class is the unit of protection in CH. This implies that class members and 
friends have access to all objects of their class for which they have a pointer, a 
reference, or a name. For example, 


class list { 

list* next; 
public: 

int on(list*); 


}; 
int list::on(list* p) 
{ 
list* g = this; 
for(:;) { 
if (p == q) return 1; 
if (q == 0) return 0; 
q = g->next; 
} 
J 


The chasing of the private list::next pointer is accepted because 
list: :on () has access to every object of class next it can somehow name. 

This can be contrasted to the approach where a member function has access 
only to the object for which it was invoked and must go through the public inter- 
face to access all other objects of its class. Following such a discipline we would 
have written something like this: 


int list::on(list* p) 


{ 
if (p == this) return 1; 
if (p == 0) return 0; 
return next->on (p); 

} 


Doing things that way provides a finer grain of control and protection at the cost of 
run-time. CH gives the programmer the choice of programming style, but unfor- 
tunately it does not provide any support for enforcing per object protection. 

Another important aspect of the C} protection system is that it applies uni- 
formly to all names. There are no special rules for data member names, function 
member names, type names, or any other names. 


si ac al | 
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11.3c Access Control 


As mentioned (§11), CH provides access control, not visibility control; that is, the 
object, function, or whatever referred to in an expression is determined without 
regard to the access specification, then type checking is done, and only if no error 
was found is access control applied. The intent is to minimize the effect of 
changes of access control and to enable a reader to understand a program without 
having to consider access control declarations. Making a name public or private 
will not quietly change the meaning of a program from one legal interpretation to 
another, 

It was noticed that people often change access status of functions during pro- 
gram development and that access control specifiers often went unnoticed by people 
reading programs. Thus it was concluded that visibility control would imply errors 
and confusion avoided by access control. For example, 


class X { 

int aa; 
public: 

void glint); 

void g (double); 
Me 


class Y : public xX { 


the Pe 
void f(); 
}; 
void Y::f() 
{ 
g(1); // call g(int); 
} 


Making X: :g (int) private will not quietly change the meaning of the call to a 
call of X::g(double). Had visibility control — rather than access control — 
been used, a quiet change of meaning would have been the result of that change. 

As far as confusion is concerned, the opposite — access control implies confu- 
sion avoided by visibility control — is also true. In such cases, however, the prob- 
lem is detected by the compiler and easily bypassed by the programmer. For 
example, 


int aa; 
void g(int); 
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class X { 
int aa; 
void g(int); 
public: 
void g(double); 
} 
class Y : public X { 
YS. wise 
void f(); 
}; 
void Y::f() 
{ 
aatt; // error: X::aa private 
g(1); // error: X::g private 
} 


Here, both the use of aa and the call of g() are resolved to X's private members. 


If the intent was to use the global names, the program is easily changed to achieve 
that. 


void Y::f() 
{ 
iiaatt; 
SeOld)'s 
} 


Had the intent been to use the public function X: :g (double), that too could 
easily be achieved. 


void Y::f() 
{ 

g(1.0); 
} 


Here is another example: 


class A { 
private: 
dump (); 
A ETO 
}; 


class B { 
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class C: public A, public B { 
void f() 
{ 
dump(); // error: ambiguous 
} 
)F 


Again, it is not obvious what the intent of the programmer was. Consequently, the 
Safest course is to rely on access control, not visibility control, and flag the ambi- 
guity. The ambiguity can be easily resolved by the user. 


class C: public A, public B { 
void f() { B::dump(); } 
}; 
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Special Member Functions 








Some member functions have special meaning in the sense that they affect the 
way a compiler treats objects of their class; that is, they affect the semantics 
even when they are not explicitly used. 


This chapter describes constructors, destructors, and conversions, and the free 
store managemen! operators, new and delete. Constructors initialize class 
objects. Destructors are invoked when class objects are destroyed; they are use- 
ful for cleaning up. A conversion function specifies a conversion between a 
class object and another type. 


Copying of class objects and the use of temporaries are also covered in this 
chapter. 


12 Special Member Functions 


Some member functions are special in that they affect the way objects of a class 
are created, copied, and destroyed, and how values may be converted to values of 
other types. Often such special functions are called implicitly. 

These member functions obey the usual access rules (§11). For example, 
declaring a constructor protected ensures that only derived classes and friends 
can create objects using it. 


m A discussion of the use of access control for special member functions can be 
found in §12.2. O 
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12.1 Constructors 


A member function with the same name as its class is called a constructor; it is 
used to construct values of its class type. If a class has a constructor, each object of 
that class will be initialized before any use is made of the object; see §12.6. 


m A constructor is called whenever an object of a class with a constructor is created. 

An object can be created in any of the following ways: 

— as a global variable, 

— as a local variable, 

— through explicit use of operator new, 

— through explicit call of a constructor, or 

— as a temporary object. 

It can also be allocated as part of another object (allocated in one of the ways above) 

— as a data member of class or 

— as an object representing a base class. 

In each case the job of the constructor is to create the basic structure of the object; 
that is, to initialize any virtual function tables, to construct the objects representing 
base classes (if any), to construct the objects representing nonstatic data members (if 
any), to lay down information that allows finding objects representing virtual bases 
(if any), and to execute the code specified in the body of the constructor (if any). 
For explicit uses of operator new, it may also be the job of the constructor to call an 
operator new () function to allocate memory. 

In other words, a constructor tums raw memory into an object for which the 
Tules of the type system hold. This process is undone by a destructor: After a 
destructor has been called, the memory that once was an object is again just bits. 
The most obvious example of the difference between raw memory and a properly 
constructed object is that virtual functions will work only after construction and 
before destruction of an object; special rules apply during construction and 
destruction (§10.9). 

The type system makes it hard, but not impossible, to use an object before it is 
completely constructed. Use of a partially constructed object is undefined since it 
would violate any explicit or implicit invariants assumed about objects of the class. 
o 


A constructor can be invoked for a const or volatile object. A construc- 
tor may not be declared const or volatile (§9.3.1). A constructor may not be 
virtual. A constructor may not be static. 


m In principle, everything that is needed to create an object is known to the program- 
mer at the point where an object is created. There is no object until after it has been 
created. The virtual mechanism exists to allow operations to be done on an object in 
the absence of knowledge of the exact type of the object. 

Sometimes one would like to create an object of a class that one does not know. 
All that one knows is that it should be ‘‘just like something else.’’ People have 
been discussing various techniques for doing this under the label ‘virtual construc- 
tors.”” Ch does not have ‘‘virtual constructors’ but it does support some simple 
techniques for handling such cases. For example, an object of a class with some 
kind of *‘clone’’ operation can be passed along and used. 
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class X { 
public: 
hese 
virtual X* clone(); // create a copy of me 
// (state copied) ey 
virtual x* newxX(); // make a default version 
// of my class (state not copied) 
}; 


X* X::clone() // default implementation 
í 


return new X(*this); // use copy constructor 
} 
X* X::inewX() // default implementation 
í 

return new X(); // use default constructor 


) 


void f(X* p) 
{ 
X* pl = p->clone(); 
X* p2 = p->newX(); 
} 
Here f () is making objects of a type about which the only thing known is that it is 
an X or a class derived from X. 

An altemative technique is to make a function that creates objects of a class X 
and pass along pointers to such functions. Such a function is described below in this 
section. The recipient of the function will now not need to know the exact type of 
the object that function creates. O 


Constructors are not inherited. Default constructors and copy constructors, 
however, are generated (by the compiler) where needed ($12.8). Generated con- 
structors are public. 


@ Consider what might happen if constructors were inherited. 


class B { 
public: 
int a; 
Bi); 
B(int); 
B(BS); 
F; 


class D ; public B { 
public: 

int b; 
i 
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ft) // note: illegal, a ‘‘what if’’ example 
{ 
B b; 
D dil; // only B part initialized 
D d2 = b; // only B part of d2 initialized 
D d3 = dl; // only B part of d3 initialized 


// this is NOT a copy 
// of derived objects! 
Ce PS // assignment to B part of D 
} 


\ Worst would be the initialization of d3. Here, inheriting the constructor from the 
` base class would quietly change the meaning of copying. The ability to assign an 
integer to a D would often be surprising. 
In fact, constructors D::D() and D::D(const D&) are generated, but the 
example still fails because there is no way of creating a D from an integer. 
Like constructors — and for the same reasons — assignment operators are gen- 
erated instead of being inherited. O 


A default constructor for a class X is a constructor of class X that can be called 
Without an argument. 


@ A default constructor is typically of the form X::X(), but a constructor that can 
be called with no arguments because it has default arguments, X: :X (int=0), for 
example, is also a default constructor. Allowing constructors with default argu- 
ments, such as X::X(int=0), is a recent extension. The restriction was con- 
sidered worthwhile because it allowed an array of objects to be initialized by a stan- 
dard function taking a pointer to function argument specifying what initialization 
needed to be done for each element in the array. Allowing default initializers forces 
the compiler to be a little bit clever about that. O 


A default constructor will be generated for a class X only if no constructor has been 
declared for class X. 

A copy constructor for a class X is a constructor that can be called to copy an 
Object of class X; that is, one that can be called with a single argument of type X. 
For example, X::X(const X&) and X::X(X&,int=0) are copy constructors. 
A copy constructor is generated only if no copy constructor is declared. 

A copy constructor for a class X may not take an argument of type X. For 
example, X: :X (X) is illegal. 


m The reason for this restriction is that passing an argument is defined as applying 
the appropriate constructor to construct the object used by the function given the 
actual argument. For example, had we been able to declare X (X), 
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X a; 
extern f(X); // note: illegal, a ‘'what if’’ example 
void g{() 
{ 
f(a); // means £(X(a)) 


// which in turn means £(X(X(a))) 
// which in turn means f£(X(X(X(a)))) 
FL gos 


) 


The restriction avoids the infinite recursion and any clever language rules that would 
have to be introduced to avoid it had X::X(X) been legal. Control of copying 
objects of class X is exercised by the declaration of a copy constructor that usually 
has the form X: :X (const X&). O 


Constructors for array elements are called in order of increasing addresses 
(§8.2.4). 

If a class has base classes or member objects with constructors, their construc- 
tors are called before the constructor for the derived class. The constructors for 
base classes are called first. See §12.6.2 for an explanation of how arguments can 
be specified for such constructors and how the order of constructor calls is deter- 
mined. 

An object of a class with a constructor cannot be a member of a union. 


m It would not have been possible to guarantee that the constructor was called for a 
union member with a constructor. For example, a union might have members of 
several classes each with their own constructors. For the same reason, objects of 
classes with destructors ($12.4) or user-defined assignments (§13.4.3) may not be 
union members. O 


No retum type (not even void) can be specified for a constructor. A return 
statement in the body of a constructor may not specify a retum value. It is not 
possible to take the address of a constructor. 


m No explicit retum value is needed because a constructor is defined to construct an 
object, and any value a function implementing a constructor may retum is an imple- 
mentation detail and invisible to the user (except when looking at generated code, 
say, with a debugger). 

The reason one cannot take the address of a constructor is that constructors have 
semantics that are closely tied to the semantics of memory allocation in all its 
varieties, and consequently the implementer (compiler writer) should not be con- 
strained to implement constructors exactly like ordinary functions. Had it been pos- 
sible to take the address of a constructor, the resulting pointer could be passed into a 
context where it was not known to be a pointer to a constructor, so it would have to 
obey all the usual rules and implementation-dependent details of other pointers to 
member functions. This would constrain the implementation of either pointers to 
members or constructors or — even worse — expose details of the implementation of 
constructors to users. The effect would eventually be to force those implementation 
details to be either incompatibilities among implementations or part of the language 


iA ipi a 


266 Special Member Functions Chapter 12 


definition. 

Note also that an explicit call of a constructor does not mean the same as the use 
of the same syntax for an ordinary member function; see the example at the end of 
this section. A constructor differs from all other nonstatic member functions in that 
it is not called for an object of its class even though it has a this pointer; it is 
called for a chunk of raw memory and must tum that into an object of its class. 


Now if the functionality of a pointer to a constructor really is needed, it can be 
obtained by indirection, as follows: 


class X { 
public: 

X(); 
Js 


void f() // not this way: 
{ 
X& (X::* p)() = &X::X; // error: cannot take 


// address of constructor 
Viena 


X* makeX(void* p = 0) 
{ 
if (p) 
return new(p) X(); // place object at ‘p’ 
else 
return new X(); 


void g() // this way! 
{ 
X* (*p) (void*) = &makex; 
PS Se 
} 


The definition of makeX() assumes a suitable overloading of operator new (). 
For example, 


// explicit placement operator: 
void* operator new(size_t, void* p) { return p; } 


o 


A constructor can be used explicitly to create new objects of its type, using the 
syntax 


class-name ( expression-listop, ) 
For example, 


complex zz = complex(1,2.3); 
cprint ( complex(7.8,1.2) ); 


An object created in this way is unnamed (unless the constructor was used as an 





Section 12.1 Constructors 267 


initializer for a named variable as for zz above), with its lifetime limited to the 
expression in which it is created; see §12.2. 
Member functions may be called from within a constructor, see §12.7. 


m Calling a constructor from within a constructor is allowed, but often what it does 
isn't what the user expected. 


class C { // warning: bad code! 
Fd NE 
public: 
Clint i) { /* common initialization */ } 
CU (1C(0)> ] 
C(char* p) { C(0); /* do stuff with ‘p’ */ } 
IF isis 
23 


Such code is sometimes written by programmers who want to factor out the common 
parts of a set of constructors. The snag is that the explicit calls of C (0) each create 
a temporary object of class C and initialize that. Such calls have no effect on the 
object the calling constructor was invoked to initialize. The way to factor out initial- 
ization code is to have an explicit initialization function that is not a constructor. 


class C { 
Uf eras 
void init(int i) { /* common initialization */ } 
public: 
Cfint i) { init(i); ) 
C() { init(0); J 
C(char* p) { init(0); /* do stuff with ‘p’ */ } 
df eats 
23 
It is often wise to make such initialization functions private. 
Making such initialization functions virtual would have no effect since it is 
not possible to refer to the yet unconstructed derived class parts of an object from 
the constructor of a base class (§10.9). O 


12.2 Temporary Objects 


In some circumstances it may be necessary or convenient for the compiler to gen- 
erate a temporary object. Such introduction of temporanes is implementation 
dependent. When a compiler introduces a temporary object of a class that has a 
constructor it must ensure that a constructor is called for the temporary object. 
Similarly, the destructor must be called for a temporary object of a class where a 
destructor is declared. 


m The implementation’s use of temporaries can be observed, therefore, through side 
effects produced by constructors and destructors. O 


For example, 
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X f(X); 


void g() 

{ 
X a(l); 
X b = £(X(2))2 
a= f(a); 


) 


Here, one might use a temporary in which to construct X(2) before passing it to 
£() by X(X&); alternatively, X(2) might be constructed in the space used to hold 
the argument for the first call of £(). Also, a temporary might be used to hold the 
result of £(X(2)) before copying it to b by X(X&); alternatively, £()'s result 
might be constructed in b. On the other hand, for many functions £ (), the expres- 
sion a=f (a) requires a temporary for either the argument a or the result of £ (a) 
to avoid undesired aliasing of a. 

The compiler must ensure that a temporary object is destroyed. The exact point 
of destruction is implementation dependent. There are only two things that can be 
done with a temporary: fetch its value (implicitly copying it) to use in some other 
expression, or bind a reference to it. If the value of a temporary is fetched, that 
temporary is then dead and can be destroyed immediately. If a reference is bound 
to a temporary, the temporary must not be destroyed until the reference is. This 
destruction must take place before exit from the scope in which the temporary is 
created. 


m The only perfectly safe rule for the destruction of temporaries would be to require 
them not to be destroyed until the last reference to them disappeared. Since this is 
not done — to avoid the overheads involved in the mechanisms needed to ensure that 
— a temporary may sometimes be destroyed earlier than a user would like. Consider 


class String { 
char *ptr; 
// initialize with concatenated string: 
String(const String &sl, const String &s2); 


as. 
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public: 
String(const char *s) ( /* set ptr */ } 
String(const String &s) { /* set ptr */ } 
~String() { delete ptr; } 
operator char*() { return ptr; } 
String cperator+(const String &s) 
( return String(*this, s); } 
}; 


void foo(const char *s) { /* do something */ } 


main() 
{ 

String x("foo"); 

String y("bar"); 

foo(x + y); // not guaranteed to work 
} 


Note, in particular, that the conversion operator passes a pointer to the representation 
of the String out of the class. The rule for destruction of temporaries allows this 
implementation: 


put x+y in templ 

convert templ to char* and put the result in temp2 
destroy templ 

foo (temp2) 


so the example may not work as apparently expected. It has been suggested that 
temporaries should be guaranteed to persist until the end of the expression in which 
they are created. That would ensure that the example above worked. Then, how- 
ever, the use of explicit variables could cause problems. 


main() 
í 

String x("foo"); 

String y("bar"); 

const chart p=x + y; 

foo (p); // still not guaranteed to work 
} 


So how about guaranteeing that temporaries persist until the end of the block in 
which they are created? That is still not good enough. 


main() 
{ 

String x("foo"); 

String y("bar"); 

const char* p; 

{ 

p=x+yr 

) 

foo(p); // still not guaranteed to work 
} 


Then how about guaranteeing that temporaries persist until the end of the function in 
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which they are created? That is still not good enough. 


const char* f() 
{ 

String x("foo"); 

String y("bar"); 

return x + y; // still not guaranteed to work 
} 


So, as stated above, the problem is that a pointer to a temporary object (or to part of 
a temporary object) was passed out of the context in which the compiler knew it 
existed. The only perfect solution for this is garbage collection. Many occurrences, 
however, can be completely analyzed at compile time. A compiler can often warn 
users about potential portability problems of such examples. For example, a 
thorough compiler with access to all source code in a program could detect the 
return of a pointer to (part of) an object from a function and wam when such a func- 
tion is applied to a temporary. The function String: :operator char*() and 
the conversions of x+y to a char* above are examples of this. In particular, since 
String::operator char*() is inline, its definition is available. Thus, enough 
information for issuing a waming (or delaying destruction) is available even in the 
presence of separate compilation. 0 


Another form of temporaries is discussed in §8.4.3. 


m A further discussion of temporaries and the possibilities for their elimination can 
be found in ($12.1). O 


12.3 Conversions 


Type conversions of class objects can be specified by constructors and by conver- 
sion functions. 

Such conversions, often called user-defined conversions, are used implicitly in 
addition to standard conversions (§4). For example, a function expecting an argu- 
ment of type X can be called not only with an argument of type X but also with an 
argument of type T where a conversion from T to X exists. User-defined conver- 
sions are used similarly for conversion of initializers (§8.4), function arguments 
(§5.2.2, §8.2.5), function retum values (§6.6.3, §8.2.5), expression operands (§5), 
expressions controlling iteration and selection statements (§6.4, §6.5), and explicit 
type conversions (§5.2.3, §5.4). 

User-defined conversions are applied only where they are unambiguous 
(§10.1.1, §12.3.2). Conversions obey the access control rules (§11). As ever 
access control is applied after ambiguity resolution (§10.4). 


m Examples of how to use access control for special member functions in general 
and conversions in particular can be found in §12.2. 0 


See §13.2 for a discussion of the use of conversions in function calls as well as 
examples below. 
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12.3.1 Conversion by Constructor 


A constructor accepting a single argument specifies a conversion from its argument 
type to the type of its class. For example, Bir 


class X ( 

// 
public: 

X (int); 

X(const char*, int = 0); 
): 


void f(X arg) { 


Xa=1; // a = X(1) 
X b = "Jessie"; // b = X("Jessie",0) 
a = 2; // a = X(2) 
f (3); // £(X(3)) 


} 


When no constructor for class X accepts the given type, no attempt is made to find 
other constructors or conversion functions to convert the assigned value into a type 
acceptable to a constructor for class X. For example, 


Glass Xf see IA RNC)? Fs 
class Y { /* ... */ Y(X); ); 
Ya=l; // illegal: Y(X(1)) not tried 


m A constant of a class type cannot appear in a program in the same sense that 1.2 
and 12e3 appear as constants of type double. A constant of an appropriate basic 
type, however, can be used where a constant of a class type is expected if a con- 
structor taking a single argument exists to provide an interpretation. Furthermore, if 
the class has a constructor simple enough to substitute inline, it is reasonable to use 
a constructor invocation as a constant. For example, 


class complex { 
double re,im; 

public: 
complex (double r, double i = 0) { re=r; im=i1; } 
PA ares 

i ` 


complex 21 = complex (1.2); 
complex z2 = 3; 


zl = complex (3.5, 7)+2.7*z2; 


Note that the last example here requires overloaded operators + and * (see 
§13.3). 

A constructor taking a single argument need not be called explicitly. This occa- 
sionally leads to unintended implicit uses of conversions. For example, 
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class Vector { 


TS ie 0% 

public: 
Vector (int s); // make vector with 's’ elements 
AASE 

J; 

void f() 

{ 
Vector v(10); // intended use 
bi ae 
v = 10; // unintended use 

} 


Here, v=10 is taken to mean convert 10 to a vector and assign, v=Vector (10). 
Strangely enough, such errors do not appear to be a genuine problem. 

When the programmer wants to be absolutely certain that no unintentional impli- 
cit conversion happens, a constructor taking a single argument can be avoided in 
favor of an explicitly named function. 


class Vector { 


private: 
Tb ICR 
Vector (int s); // make vector with 's’ elements 
public: 
static Vector make(int s) { return Vector(s); } 
Vd valor 
J2 
void f() 
{ 
Vector v = Vector::make(10); 
sare 
v = 10; // error: private constructor 


v = Vector::make(10); // ok 


12.3.2 Conversion Functions 


A member function of a class X with a name of the form 


conversion-function-name: 
operator conversion-type-name 


conversion-type-name: 
type-specifier-list ptr-operator,,, 


specifies a conversion from X to the type specified by the conversion-type-name. 
Such member functions are called conversion functions. Classes, enumerations, and 
typedef-names may not be declared in the type-specifier-list. 
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m Conversion functions can do two things that cannot be specified by constructors: 
1. Define a conversion from a class to a basic type, 


2. Define a conversion from one class to another without modifying the declara- 
tion for the other class. 


o 


Neither argument types nor retum type may be specified. 


m For example, 


class X { 
int* operator int*(); // error 
operator void’ (int); // error 
operator char*(); // ok 

}; 


Here is an example: 


class X { 

// 
public: 

operator int(); 
F? 


void f(X a) 

{ 
int i = int(a); 
i = (int)a; 
i = a; 


) 


In all three cases the value assigned will be converted by X:: operator int (). 


User-defined conversions are not restricted to use in assignments and initializations. 
For example, 


void g(X a, X b) 


{ 
int i = (a) ? lta: 0; 
int j = (a&&b) ? atb : i; 
Sf (ate fii. 
} 

} 


Conversion operators are inherited. 


m For example, 
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Struct S t 
operator int{); 
}; 


struct SS : public S { }; 


void f{) 
{ 
SS a; 
int i =a; // i = a.S::operator int () 


D 


Conversion functions can be virtual. 


@ For example, 


#finclude <iostream.h> 


class X { 
public: 

virtual operator const char*() { return "X"; } 
}; 


class Y : public X { 
operator const char*() { return "Y"; ) 
Me 


void main{() 
{ 
X* p = new Y; 
cout << *p << ‘\n’; // prints "y" 


At most one user-defined conversion (constructor or conversion function) is 
implicitly applied to a single value. For example, 


public: 
public: 


operator X(); 
}; 


bei 
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Y a; 
int b = a; // illegal: 
// a.operator X().operator int() not tried 
int c = X(a); // ok: a.operator X().operator int() 
User-defined conversions are used implicitly only if they are unambiguous. 


m Ambiguities can arise both from multiple choices of user-defined conversions and 
from multiple choices between user-defined and built-in conversions. Consider, for 
example, 


class Boolean { 
int b; 
public: 
Boolean operator+ (Boolean); 
Boolean(int i) { b = i!=0; } 
operator int() { return b; } 
h; 


Boolean bool (1); 


Given this, an expression like (bool+1) would be ambiguous because it could be 
interpreted as either 


(bool.operator int{) + 1) 
or 
(bool.operator + (Boolean(1))) 
The user can avoid the ambiguity by explicitly writing the expression intended. O 
@ Defining a conversion by both a constructor and a conversion function can lead to 
ambiguities. For example, 


class B; 


Me 


class B { 
public: 
Pian 
operator A(); 
h; 


A a= b; // error: A(b) or b.operator A() ? 
(B) 


A conversion function in a derived class does not hide a conversion function in a 
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base class unless the two functions convert to the same type. For example, 


class X { 
public: 
Fda 
operator int(); 


}; 


class Y : public x { 
public: 

// 

operator void*(); 


}3 


void f(Y& a) 
{ 
Tt Cay f // error: ambiguous 
// 
) 


w That is, conversions to different types are considered functions with different 
names, not as overloaded versions of a function of the same name. 

This rule has the desirable property of allowing the maximum number of poten- 
tial ambiguities to be caught. O 


m Note that since conversion functions do not take arguments, they cannot be over- 
loaded. O 


12.4 Destructors 


A member function of class cl named ~c1 is called a destructor; it is used to des- 
troy values of type cl immediately before the object containing them is destroyed. 


m Another way of looking at a destructor is as an operation that reverses the effect 
of a constructor: A destructor tums an object into raw memory. O 


A destructor takes no arguments, and no return type can be specified for it (not 
even void). It is not possible to take the address of a destructor. 


m As with constructors (§12.1), this restriction is imposed to allow the compiler 
writer the freedom to implement destructors in ways that are different from ordinary 
member functions. In particular, one popular technique for implementing destructors 
involves a hidden argument specifying whether memory in which the object is allo- 
cated should be deallocated by the destructor and whether destructors should be 
called for virtual base classes. 

If the equivalent to the address of a destructor is needed, wrap an explicit call to 
the destructor in a function, preferably a virtual member function for safety, and pass 
the pointer to that function instead; see §12.1. O 
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A destructor can be invoked for a const or volatile object. A destructor may 
not be declared const or volatile (§9.3.1). A destructor may not be static. 

Destructors are not inherited. If a base or a member has a destructor and no 
destructor is declared for its derived class a default destructor is generated. This 
generated destructor calls the destructors for bases and members of the derived 
class. Generated destructors are public. 

The body of a destructor is executed before the destructors for member objects. 
Destructors for nonstatic member objects are executed before the destructors for 
base classes. Destructors for nonvirtual base classes are executed before destructors 
for virtual base classes. Destructors for nonvirtual base classes are executed in 
reverse order of their declaration in the derived class. Destructors for virtual base 
classes are executed in the reverse order of their appearance in a depth-first left-to- 
right traversal of the directed acyclic graph of base classes; ‘‘left-to-right’’ is the 
order of appearance of the base class names in the declaration of the derived class. 


m Look at the diagram in §12.6.2 illustrating construction order. The order of 
destruction is the reverse of the order of construction. O 


€ Note that all calls of member and base destructors are implicit; the programmer 
need not — and should not try to — write any code to make this happen. See §12.6.2 
for a further discussion of declaration order. O 


Destructors for elements of an array are called in reverse order of their construc- 
tion. 


A destructor may be virtual. 


@ It is often a good idea to declare a destructor virtual. If a destructor is not virtual 
one can get caught in this mess: 


class B { 
TF ec 
public: 
Bi); 
~B(); 
Me 


class D : public B { 
LE ess 

Public: 
Di); 
~D(); 

Me 


void f() 
{ 
B* p = new D(); // create a D 
delete p; // delete a B 
} 


Since B's destructor was not virtual, the delete statement calls B::~B() and not 
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D::~D() as was presumably needed for correct operation. Declaring B::~B() 
virtual solves the problem. 


class B { 

iia as 

Bi); 

virtual ~B(); 
}; 


Note that if a class has a destructor, all its derived classes are guaranteed to have 
destructors. 


So why are destructors not virtual by default? The reason is that an object with 


- a Virtual function needs some form of data that allows it to determine which version 


of a virtual function to call. Typically, that is a pointer to a table of virtual func- 
tions, a vptr (see §10.7, §10.8). Sometimes it is undesirable to add such data. 
This overhead can be critical when many small objects are involved and even worse 
when it increases the size of something that would fit in a register into something 
that cannot. In both cases, a point defined as two 16-bit integers can be an exam- 
ple; with a vptr added, such a point would have a 64-bit representation. Even 
worse, adding a vptr makes a storage layout that is distinctively CH, which is 
unacceptable for data structures that have to be shared with code written in other 
languages. For example, the class describing an I/O layout for a machine with 
memory mapped I/O, an array of complex numbers to be given to a Fortran library, 
or a C operating system data structure must not be modified quietly by a CH com- 
piler for the convenience of the programmer. 

As a rule of thumb, declare a virtual destructor in every base class that has a vir- 
tual function. O 


Member functions may be called from within a destructor; see §12.7. 

An object of a class with a destructor cannot be a member of a union. 

Destructors are invoked implicitly (1) when an auto (§3.5) or temporary 
(§12.2, §8.4.3) object goes out of scope, (2) for constructed static (§3.5) objects at 
program termination (§3.4), (3) through use of the delete operator (§5.3.4) for 


objects allocated by the new operator (§5.3.3), and (4) explicitly using the 


destructor’s fully qualified name. When invoked by the delete operator, memory 


is freed by the destructor for the most derived class (§12.6.2) of the object using an 
operator delete () (§5.3.4). For example, 


class X { 
Whe 
public: 
X (int); 
~X(); 
}; 


void g(X*); 


ote, 
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void f() // common use: 
{ 
X* p = new X(111); // allocate and initialize 
g(p); 
delete p; // cleanup and deallocate 
} 


Explicit calls of destructors are rarely needed. One use of such calls is for objects 
placed at specific addresses using a new operator. Such use of explicit placement 
and destruction of objects can be necessary to cope with dedicated hardware 
resources and for writing memory management facilities. For example, 


void* operator new(size t, void* p) { return p; } 
void f(X* p); 


static char buf[sizeof(X)); 


void g() // rare, specialized use: 
{ 
X* p = new(buf) X(222); // use buf[) 
// and initialize 
f (p); 
p->X::-X(); // cleanup 


m An explicit call of a destructor must use -> or . explicitly. An attempt to rely on 
implicit use of the this pointer would lead to confusion between the use of the ~ 
as part of the name of the destructor and using the unary ~ operator (§5.3). 


class X [Í 
TF, slave 
public: 
X(); 
virtual ~X(); 
Xs operator~(); 


void f(); 
Tha ats 
I; 
void X::f() 
{ 
X aa = X(); // construct an X 
~aa; // apply complement operator to ‘aa’ 
aa.~X(); // destroy ‘aa’ 
this->-X(); // destroy ‘*this’ 
~X(); // create an X and complement it 
} 


Explicitly calling destructors should be limited to the rare cases when it genuinely is 
needed. O 
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m As usual, explicit qualification of a function name in a call suppresses the virtual 
function call mechanism. For example, 


class XX : public X { 


IS ees 
public: 
~XX(); // note that X::~X was virtual 
ye 
void g() 
{ 
XX a; 
extern ggq(X&); 
h(a); 


void h(X& a) 
{ 
a.X22-X(); // static call 
a.~X(); // virtual call 
} 


The call h(a) in g() will cause the second destructor call in h() to invoke XX’s 
destructor. O 


The notation for explicit call of a destructor may be used for any simple type 
name. For example, 


p->int::~int(); 


Using the notation for a type that does not have a destructor has no effect. Allow- 
ing this enables people to write code without having to know if a destructor exists 
for a given type. 


12.5 Free Store 


When an object is created with the new operator, an operator new () function 
is (implicitly) used to obtain the store needed (§5.3.3). 

If operator new() cannot allocate storage or if it is called with the argu- 
ment 0 it will return 0. 


m The programmer can affect the behavior of the default operator new () by cal- 
ling a function 


extern void (*set_new_handler (void(*) ())) (); 


declared in the standard header <new.h>. If operator new() cannot find 
Storage to retum, it calls a function — often referred to as the ‘‘new-handler’’ — 
determined by the last call of the function set_new_handler(). A call of 
set_new_handler() returns the old new-handler and makes its argument the 
new-handler. A zero argument indicates to set_new_handler() that no new- 
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handler should be used; that is also the default setting. If there is a new-handler, 
operator new() will call it and make another attempt to allocate memory. Here 
is a simple example of a set_new_handler (): 


typedef void (*PFVV) (); 


extern PFVV _new_handler = 0; 


extern PFVV set_new_handler(PFVV handler) 
{ 

PFVV rr = _new_handler; 

_new_handler = handler; 

return rr; 
} 


Here is an example of a simple operator new (): 


include <stdlib.h> 


extern void* _last_allocation; 


extern void* operator new(size t size) 


{ 
void* p; 


while ( (p=malloc(size))==0 ) { 
if (_new_handler) 
(*_new_handler) (); 
else 
return 0; 


} 


return _last_allocation=p; 


o 


An X::operator new () for a class X is a static member (even if not expli- 
citly declared static). Its first argument must be of type size_t, an 
implementation-dependent integral type defined in the standard header 
<stddef.h>; it must retum void*. For example, 


class X { 
// 
void* operator new(size t); 
void* operator new(size t, Arena*); 


}; 


m The reason that X: :operator new () and X::operator delete () must be 
static members is that they are called before the constructor and after the destructor, 
respectively. In other words they do not operate on an object of class X; rather, they 
allocate the memory in which a constructor will create an object of class X and on 
some memory in which a destructor just destroyed an object of class X, respectively. 
Giving them a this pointer (that is, allowing them to be nonstatic) would simply 
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give these functions data and functions that could not be used with even the most 
minimal degree of safety. 

The degree of separation between allocation and initialization (and between 
deallocation and cleanup) that this implies makes for cleaner programs. O 


See §5.3.3 for the rules for selecting an operator new (). 


m Note that the usual scope, access, and overloading rules apply to calls of 
operator new(). The following, for example, is an error: 


class X { 
private: 
void* operator new(size t); 
Public: 
X(); 
he 


X* p = new X; // error X::operator new() is private 


Consider also, 


class Y { 

Lf eee 
Public: 

void *operator new (size_t size, int flag); 
Me 
Y* pl = new Y; // error: tries to call 

// Y::operator new(size _t) 

¥* p2 = new(7) Yz // ok: 


// calls ¥::operator new(size_t,int) 


The reason is that the declaration of Y: :operator new() has hidden the global 
operator new (). 
A more subtle version of this error may occur when a constructor is defined. 


class Y { 
fI oss 

public: 
void *operator new (size t s, int flag); 
Y() {) // may be error 

Me 


Here, an implementation is allowed to place a call of operator new() in the 
body of the constructor to implement the constructor semantics (see §12.1). If it 
does so, it will call an operator new() with a single argument, bul 
Y: :operator new () requires two. 

In either case, the solution is to provide a Y: soperator new () that accepts 4 
single argument. For example, 
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class Y { 
Liste 
public: 
void *operator new (size t s) 
{ return ::operator new(s); } 
void *operator new (size t s, int flag); 
J}; 
Naturally, if a call to an operator new() is embedded in a constructor by the 
implementation, it will be used only for invocations of new for which it is appropri- 
ate. O 


An X::operator delete() fora class X is a static member (even if not 
explicitly declared static) and must have its first argument of type void*; a 
second argument of type size_t may be added. It cannot retum a value; its 
return type must be void. For example, 


class X { 

VP rovers 

void operator delete (void*) ; 
Vi 


class Y { 

LP ene 

void operator delete(void*, size t); 
}; 


Only one operator delete() may be declared for a single class; thus 
operator delete () cannot be overloaded. The global operator delete () 
takes a single argument of type void*. 

If the two argument style is used, operator delete () will be called with a 
second argument indicating the size of the object being deleted. The size passed is 
determined by the destructor (if any) or by the (static) type of the pointer being 
deleted; that is, it will be correct either if the type of the pointer argument to the 
delete operator is the exact type of the object (and not, for example, just the type 
of base class) or if the type is that of a base class with a virtual destructor. 


w Note that if the base class has a destructor, then a destructor will exist for all 
classes derived from it. If the user doesn’t declare one, a default version is gen- 
erated. Since the size of an object of the class is known where a destructor is 
defined, the information necessary for getting the size nght is always available for a 
class with a virtual destructor. O 


The global operator new() and operator delete () are used for arrays 


of class objects (§5.3.3, §5.3.4). 
Since X::operator new() and X::operator delete() are static 


they cannot be virtual. 
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m They are inherited, though. O 


A destructor finds the operator delete() to use for freeing store using the 
usual scope rules. For example, 


struct B { 
virtual ~B(); 
void* operator new(size t); 
void operator delete (void*); 
J3 


struct D: B { 
~D(); 
void* operator new (size_t); 
void operator delete (void*); 
); 


void f() 

{ 
B* p = new D; 
delete p; 

} 


Here, storage for the object of class D is allocated by D: :operator new () and, 
thanks to the virtual destructor, deallocated by D: :operator delete (). 


12.6 Initialization 


An object of a class with no constructors, no private or protected members, no vir- 
tual functions, and no base classes can be initialized using an initializer list; see 
§8.4.1. An object of a class with a constructor must either be initialized or have a 
default constructor (§12.1). The default constructor is used for objects that are not 
explicitly initialized. 


12.6.1 Explicit Initialization 


Objects of classes with constructors (§12.1) can be initialized with a parenthesized 
expression list. This list is taken as the argument list for a call of a constructor 
doing the initialization. Alternatively a single value is specified as the initializer 
using the = operator. This value is used as the argument to a copy constructor. 
Typically, that call of a copy constructor can be eliminated. For example, 
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class complex { 
liE 

public: 
complex (); 
complex (double) ; 
complex (double, double) ; 
// 

}; 
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complex sqrt (complex, complex); 


@ Note that since class complex has constructors it is considered to have a public 
copy constructor with the default implementation even though no copy constructor is 


explicitly declared (§12.1). O 


complex a(l); // 
// 
complex b = a; // 
complex c = complex(1,2); // 
// 
// 
complex d = sqrt(b,c); // 
// 
complex e; // 
// 
complex f = 3; // 
// 
// 


@ For each of these, a compiler will be able 


initialize by a call of 
complex (double) 

initialize by a copy of ‘a’ 
construct complex (1,2) 

using complex (double, double) 
copy it into ‘c’ 

call sqrt (complex, complex) 
and copy the result into ‘d’ 
initialize by a call of 
complex () 

construct complex(3) using 
complex (double) 

copy it into ‘f’ 


to construct the complex value directly 


in the variable created (see §12.1, §12.8), but only for a and e is the compiler 
required to do so; in the other cases a temporary object may be used (§12.2). Note, 
however, that access control is applied for the copy constructor (§11), so had 
complex(const complexé) been private only the declarations of a and e 


would have been legal. O 


Overloading of the assignment operator = has no effect on initialization. 


m Specifying initialization using = as normal expression evaluation followed by a 
copy operation (that is usually optimized away) has three effects: 

— The set of values acceptable for initialization and assignment will be identi- 

cal except where the user specifically defines constructors and/or assignment 


operators to ensure they are not. 


— Access control is applied for the copy constructor (just as it is for assign- 


ment). 


— The use of a temporary and its possible elimination are explicitly allowed, 
giving implementers a degree of freedom that is sometimes needed. 
Note that initialization and assignment are generally very different operations. 
Initialization occurs wherever an object is created. That is, 
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— when a variable is defined with an explicit initial value, 
— when a variable is defined without an explicit initial value but the variable is 
of a class with a default constructor, 
— when a function retums a value, 
— when an argument is passed, 
— when an explicit or implicit conversion in an expression results in the crea- 
tion of an object with a constructor, 
— when an object is created with the new operator with an explicit initial 
value, 
— when an object is created with the new operator without an explicit initial 
value but the object is of a class with a default constructor, and 
— when a constructor is used explicitly in an expression. 
Assignment occurs when an assignment operator is used in an expression. An 
assignment operation will always invoke a predefined, user-defined, or default 
assignment operator. The left operand of an assignment is always a previously con- 
structed object, whereas an object being initialized never is. Assignment operations 
typically rely on being invoked only for fully constructed objects. 
Initialization of a declared variable (or constant) takes a variety of syntactic 


forms. 
T x(a); 
TXT a; 
T x = T(a); 
T x = (T)a; 


These are most often equivalent, but there are distinctions that are of interest mostly 
to compiler writers. We will ignore built-in types and consider only classes. Con- 
sider 


struct T { 
T(int); // conversion: int -> T 
T(const T&); 


struct S { 
operator T(); // conversion: S -> T 
}; 


S a; 


T xl =a; 

T x2(a); 

T x3 = T(a); 
T x4 = (T) (a); 


All these initializations are legal, but not for the same reasons, Where the explicit = 
is used, the meaning is ‘‘construct the value specified in a temporary object, and 
then copy it to the variable being initialized using the copy constructor.’ A g00 
compiler notices that there is no need to introduce the temporary and eliminates i. 
For 
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T x2(a); 


a constructor (which happens to be the copy constructor) is called directly for x2. 
Constructing the copy constructor's argument using the conversion function, how- << 
ever, May require a temporary. 
Had no copy constructor been declared for T, all would have happened exactly 
as before because a copy constructor would have been generated. Again, a good 
compiler would eliminate the use of the generated copy constructor. 
Had T's copy constructor been private, a difference could have been detected. 


class T { 
T(const T&); 
Public: 
T(int); 
Il; 
TSIN? // ok 
T x6 = T(1); // error: T::T(const T6) is private 


In both cases, T: :T (int) is called to create the T. In the latter case, however, the 
copy constructor is needed to initialize x6, and since we assumed it to be private, 
the initialization fails. The temporary can be eliminated (§12.1), but the semantics 
are not affected. 

Except for access control issues and the possible use of temporaries, the forms 


T x(a); 
T x = T(a); 
T x = (T)a; 


are always equivalent. The forms 


and 
T x = T(a); 


differ in that the latter is considered a direct call of a conversion function or a con- 
structor, whereas an implicit user-defined conversion is involved in the former. 
Since at most one user-defined conversion is implicitly applied to a value in a single 
expression (§13.2) this can lead to differences. For example, 


class Vector { 
public: 

Vector (int); 
}; 


class Bignum { 
public: 

operator int(); 
Me 
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void f() 
{ 
Bignum b; 
VI ans 
Vector vl {(b); // ok 
Vector v2 = Vector(b); // ok 
Vector v3 = b; // error: max one implicit 


// user-defined conversion 


) 


Access control is applied to user-defined conversions just as it is to all other func- 
tions (§11). Similarly, ambiguity contro! is applied to initialization involving user- 
defined conversions just as it is to all other function calls (§10.1.1). For example, 


struct X { 
l; 


struct T f 
T(int); 
T(X); 

Ve 


struct S { 
operator int(); 
operator X(); 
MF 


4 
x 
n 


T(a); // error: ambiguous 
// T(a.operator int()) or T(a.operator X()) 


An example of each form of class object initialization follows: 


Tx =a; // make a T from ‘a’, then copy it to ‘x’ 
// max 1 implicit user-defined conversion 


Tx =T(a); // make a T from ‘a’, then copy it to ‘x’ 
// max 1 implicit user-defined conversion 
// plus the explicit conversion to T 


Tx = (T)a; // identical to T x = T(a); 


T x(a); // call a constructor for T, 
// maybe the copy constructor 


The initialization that occurs in argument passing and function retum is 
equivalent to the form 


Tx = a; 


The initialization that occurs in new expressions (§5.3.3) and in base and member 
initializers (§12.6.2) is equivalent to the form 
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T x(a); 


m For built-in types, the only differences are between forms that are explicit casts 
and forms that are not. For example, 


typedef int* T; 


TEI ESTs // error: cannot initialize int* with int 
T x2(1); // error: cannot initialize int* with int 
T 3 = T // ok: explicit cast to int* 
T x4 = (T)1; // ok: explicit cast to int* 


(a 


Arrays of objects of a class with constructors use constructors in initialization 
(§12.1) just like individual objects. If there are fewer initializers in the list than 
elements in the array, the default constructor (§12.1) is used. If there is no default 
constructor the initializer-list must be complete. For example, 


complex cc = { 1, 2 }; // error; use constructor 
complex v[6] = { 1,complex(1,2),complex(),2 }; 


Here, v[0] and v{3] are initialized with complex: :complex (double), 
v[1] is initialized with complex: :complex (double, double), and v[(2], 
v[4], and v[5] are initialized with complex: : complex (). 


@ In other words, given a default constructor that initializes a complex number to 
(0,0), the initializations above are equivalent to this more explicit variant: 
complex v[6] = { 
complex (1,0), 
complex(1,2), 
complex (0,0), 
complex (2,0), 
complex (0,0), 
complex (0,0) 
ie 


o 


An object of class M can be a member of a class X only if (1) M does not have a 
constructor, or (2) M has a default constructor, or (3) X has a constructor and if 
every constructor of class X specifies a ctor-initializer (§12.6.2) for that member. 
In case 2 the default constructor is called when the aggregate is created. If a 
member of an aggregate has a destructor, then that destructor is called when the 
aggregate is destroyed. 

Constructors for nonlocal static objects are called in the order they occur in a 
file; destructors are called in reverse order. See also §3.4, §6.7, §9.4. 


@ A static array member can be initialized in a definition outside the class declara- 
tion, as in this example: 
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struct Tablel { 
static const int powers[8); 
static int values{[4]; 
Me 
const int Tablel::powers[8]) = (2,4, 8,16, 32, 64,128,256); 
int Tablel::values[4] = {0,0,0,0); 


A nonstatic array member that is not const can be initialized in each object of 
the class type with supplied or default argument values in a constructor, as follows: 


struct Table2 { 
int tbl[2]; 


Table2 (int tbl0=255, int tbl1=256) { 
tbl[0)=tbl0o; 
tbl{1)=tb1l1; 
}; 
}; 


There is, however, no member initialization syntax for nonstatic const arrays. 
For example, 


struct Tabled { 
const int tbl[2); 


Table4() : tb1(99,100) {]}; // syntax error 
Tabled() : tbl{99,100) {}; // syntax error 
Table4() : tbl1({99,100)) {}; // syntax error 


}; 


A nonstatic member that is not an array, whether const or not, can be initialized 
through a member initialization list, as follows: 
struct Table? { 
int (*tbl)[]; 


const int max; 
int size; 


Table3() : max(64), size(16) {}; 
Me 


12.6.2 Initializing Bases and Members 


Initializers for immediate base classes and for members not inherited from a base 
class may be specified in the definition of a constructor. This is most useful for 
class objects, constants, and references where the semantics of initialization and 
assignment differ. 


m Disallowing the initialization of indirect bases and of inherited members prevents 
multiple initializations of a single base or member. 


bis. 
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class X f 
public: 
inté x; 
X0); 
A(intée T) < aIr P E S) 
~X(); 
Js 
class B : public X { 
public: 
int b; 
BANE 2s Kis BAN G LE ean A 
Me 


class D: public B { 
int d; 
int d2; 
public: 
Dit} t B(2), 
b(3), // error: ‘b’ is inherited 
X(d), // error: ‘X’ is an indirect class 
x(d2) // error: ‘x’ is inherited 
{ AE cx: BF J 


A ctor-initializer has the form 


ctor-initializer: 
: mem-initializer-list 


mem-initializer-list: 
mem-initializer 
mem-initializer , mem-initializer-list 


mem-initializer: 
complete-class-name ( expression-list,., ) 
identifier (  expression-list,, ) 


€ See §18.3 for the old *‘:(expression-list)’’ form of base class initializers. O 


The argument list is used to initialize the named nonstatic member or base class 
object. This is the only way to initialize nonstatic const and reference members. 


For example, 





292 Special Member Functions Chapter 12 


struct Bl { Bl(int); /* ... */ }; 
struct B2 { B2(int); /* ... */ }; 


Struct. Desa B12 B2 E 
D(int); 
Bl b; 
const c; 


}; 


D::D(int a) : B2(a+1), Bl(a+2), c(a+3), b(a+4) 
(Sa Ra) 


D d(10); 


First, the base classes are initialized in declaration order (independent of the order 
of mem-initializers), then the members are initialized in declaration order (indepen- 
dent of the order of mem-initializers), then the body of D::D() is executed 
($12.1). The declaration order is used to ensure that sub-objects and members are 
destroyed in the reverse order of initialization. 

Virtual base classes constitute a special case. Virtual bases are constructed 
before any nonvirtual bases and in the order they appear on a depth-first left-to- 
right traversal of the directed acyclic graph of base classes; ‘‘left-to-right’’ is the 
order of appearance of the base class names in the declaration of the derived class. 


m Consider 
CLASS ATIZAN a AAA 7 
class UBT / 2 owe AAI? 
class C : public virtual A, public virtual B { /* ... */ F 
Class D : public virtual B, public virtual A { /*... */ }é 
class E : public C, public D { /* ... */ }; 


The usual way of drawing the sub-objects simply obscures the order of initialization 
of virtual base objects by not representing the order of declaration of A and B in C 
and D adequately. 


A B 


ee 


Drawing each occurrence of a virtual base separately even though there is only one A 
and one B in an E helps. 


C 
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NY, v 
= 


The order of construction is 

C’s A 

C’s B 

G 

(D’s B already done, ignore) 
(D's A already done, ignore) 
D 

E 


A complete object is an object that is not a sub-object representing a base class. 
Its class is said to be the most derived class for the object. All sub-objects for vir- 
tual base classes are initialized by the constructor of the most derived class. If a 
constructor of the most derived class does not specify a mem-initializer for a virtual 
base class then that virtual base class must have a default constructor or no con- 
structors. Any mem-initializers for virtual classes specified in a constructor for a 
class that is not the class of the complete object are ignored. For example, 


class V { 


}; 


class A : public virtual V { 
public: 

A(); 

A(int); 

SJ 
}; 


class B : public virtual V { 
public: 

B(); 

B(int); 

Lh aan 
}; 
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class C : public A, public B, private virtual V { 


public: 

C(); 

Cne) i 

// 
}; 
ADsA(nt Ey os Wi) LL ee OF 
Bi SBdint D N AS Rice VA 
CrsGiGint iy T ZE aie aie 
Y v(1); // use V(int) 
A a(2); // use V(int) 
B b(3); // use V() 
C c(4); // use V() 


A mem-initializer is evaluated in the scope of the constructor in which it 
appears. For example, 


class: X { 

int a; 
public: 

const inté& r; 

XO Tal {3 
}; 


initializes X: : r to refer to X: :a for each object of class X. 


12.7 Constructors and Destructors 


Member functions may be called in constructors and destructors. This implies that 
virtual functions may be called (directly or indirectly). The function called will be 
the one defined in the constructor’s (or destructor’s) own class or its bases, but not 
any function overriding it in a derived class. This ensures that uncons 
objects will not be accessed during construction or destruction. For example, 


class x { 
public: 
virtual void f(); 
KI A EA // calls X::£() 
X). AEO DO Af carrs xs 20) 
de 
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class Y : public X { 
inté r; 

public: 
void f() 
{ 


l r++; // disaster if ‘r’ is uninitialized 
Y(int& rr) :xr(rr) {} 
Ky 


The effect of calling a pure virtual function directly or indirectly for the object 


being constructed from a constructor, except using explicit qualification, is unde- 
fined (§10.3). 


12.8 Copying Class Objects 


A class object can be copied in two ways, by assignment (§5.17) and by initial- 
ization ($12.1, §8.4) including function argument passing (§5.2.2) and function 
value return ($6.6.3). Conceptually, for a class X these two operations are imple- 
mented by an assignment operator and a copy constructor (§12.1). 


m In practice, a good compiler can generate bitwise copies for most class objects 
since they have the bitwise copy semantics; no assignment function must be gen- 
erated unless the user takes its address. O 


The programmer may define one or both of these. If not defined by the program- 
mer, they will be defined as memberwise assignment and memberwise initialization 
of the members of X, respectively. 

If all bases and members of a class X have copy constructors accepting const 
arguments, the generated copy constructor for X will take a single argument of type 
const X&, as follows: 


X::X(const XE) 
Otherwise it will take a single argument of type X&: 
X::X(X&) 


and initialization by copying of const X objects will not be possible. 

Similarly, if all bases and members of a class X have assignment operators 
accepting const arguments, the generated assignment operator for X will take a 
single argument of type const X&,asfollows: 


X& X::operator=(const X&) 
Otherwise it will take a single argument of type X&: 
X& X::operator=(X&) 


and assignment by copying of const X objects will not be possible. The default 
assignment operator will return a reference to the object for which is invoked. 
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Objects representing virtual base classes will be initialized only once by a gen- 
erated copy constructor. Objects representing virtual base classes will be assigned 
only once by a generated assignment operator. 


@ This can be achieved only by a consistent strategy for all constructors and assign- 
ment operators. For example, every constructor of a class with a virtual base could 
be given a hidden argument indicating whether the virtual base has already been 
constructed. Such consistency is not easily achieved for, say, user-defined assign- 
ment operators, O 


Memberwise assignment and memberwise initialization implies that if a class X 
has a member of a class M, M's assignment operator and M's copy constructor are 
used to implement assignment and initialization of the member, respectively. If a 
class has a const member, a reference member, or a member or a base of a class 
with a private operator=(), the default assignment operation cannot be gen- 
erated. Similarly, if a member or a base of a class M has a private copy constructor 
then the default copy constructor cannot be generated. 

The default assignment and copy constructor will be declared, but they will not 
be defined (that is, a function body generated) unless needed. That is, 
X::operator=() will be generated only if no assignment operation is explicitly 
declared and an object of class X is assigned an object of class X or an object of a 
class derived from X or if the address of X: :operator= is taken. Initialization 
is handled similarly. 

If implicitly declared, the assignment and the copy constructor will be public 
members and the assignment operator for a class X will be defined to return a refer- 
ence of type X& referring to the object assigned to. 

If a class X has any X: :operator=() that takes an argument of class X, the 
default assignment will not be generated. If a class has any copy constructor 
defined, the default copy constructor will not be generated. For example, 


class X { 

Ni fi! 
public: 

X(int); 

X(const X&, int = 1); 
}; 


X a(1); // calls X(int); 
X b(a,0); // calls X(const X&,int); 
X c= b; // calls X(const X&,int); 


m Consider also, 
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class Y { 
public: 
Y& operator=(int); 
Y(int); 
de 
void f() 
{ 
Yasi; 
Yb= a; // ok 
a = b; // ok 
} 


In other words, unless explicitly declared private, copy operations are available 
for class objects. O 


Assignment of class objects X is defined in terms of X: :operator=(const 
X&). This implies (§12.3) that objects of a derived class can be assigned to objects 
of a public base class. For example, 


class X { 
public: 

int b; 
}; 


class Y : public X { 
public: 

int c; 
}; 


| void f() 
{ 
Xe 
Y yl; 


xl = yl; // ok 
yl = xl; // error 


} 


Here y1.b is assigned to x1.b and y1.c is not copied. 


m Quietly slicing an object in two and using only part of it in the assignment seems 
dangerous. The possibility of doing this, however, follows directly from the type 
rules of the language. Disallowing it involves arguing against the rule that ‘an 
object of a derived class can be used wherever an object of a base class can be 
used,” which would be hard to justify. 

Consider protecting the programmer against the slicing assignment operation 
above. A major variant of the problem would remain even if the compiler made 
xl=y1 an error, 
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void f() 
í 

X xl; 

Y yl; 

X* px = &yl; 

xl = *px; // yl is sliced! 
} 


Any serious attempt to protect the user against slicing copy operations would involve 
a prohibition against assignments and initializations involving pointers and refer- 
ences. This does not seem sensible and would constitute a major incompatibility 


with C. O 


Copying one object into another using the default copy constructor or tbe 
default assignment operator does not change the structure of either object. For 


example, 


struct s { 
virtual f(); 


r A eee 

}; 

struct ss : public 
£(); 
Lido E 

}; 

void f() 

{ 
S a; 
ss b; 
a = b; // 
b= a; // 
a.£()3 // 
b.f(); // 
(s&)b = a; // 

// 

b.£(); // 


) 


The call a.£() will invoke s: 


s { 


really a.s::operator=(b) 

error 

calls s::f 

calls ss::f 

assign to b's s part 

really ((s&)b).s::operator=(a) 
still calls ss::f 


:£() (as is suitable for an object of class S 


(§10.2)) and the call b.£() will call ss::£() (as is suitable for an object of 


class ss). 


m Note that an object of a class X with a constructor is still acceptable as an argu- 
ment to a function that uses the ellipsis rather than a specific argument declaration 


(§8.2.5). For example, 
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class X { 
Chater | 
X(const X4); 
}; 
INE) f(Int senri 


void g(X aa) 
{ 
f(1,aa); // aa’s contents copied without 
// the use of the constructor! 
) 


What happens is that the representation of aa is passed. What is transmitted is not 
an object of class X; should the constructors and destructors of X, or any other 
functions, maintain a use count or a list of objects of class X, then that accounting 
is not affected by an X used as an argument for the ellipsis. 

Clearly this mechanism breaks the type system. It provides a way of obtaining 
a copy of the representation of an object. This can be useful for low-level applica- 
tions. Note that the receiver (that is, the definition of the function with an ellipsis 
argument) does not receive an object of class X, and if one is needed, one will 
have to be made — using proper construction — based on the information passed. 

Such copying is clearly implementation dependent for all but the simplest 
classes. If a class has virtual functions or virtual base classes the representation 
passed will contain ‘‘housekeeping"’ information about which no general assump- 
tions can be made. O 





Commentary 


This commentary section discusses how to eliminate temporary objects, tells how to 
use access control with the special member functions, and gives a table summariz- 
ing the built-in properties of special member functions. 


12.1lc Temporary Elimination 


The introduction of temporary objects is often necessary, especially when handling 
expressions involving overloaded operators. Such temporaries, with the calls of 
constructors, destructors, and copy operations they imply, can be expensive. The 
question is, ‘how aggressive can a compiler be in optimizing these temporaries 
away?’ Or stated the other way, “‘when can a compiler avoid introducing such 
temporaries?"’ 

The fundamental rule is that the introduction of a temporary object and the calls 
of its constructor/destructor pair may be eliminated if the only way the user can 


300 Special Member Functions Chapter 12 


detect its elimination or introduction is by observing side effects generated by the 
constructor or destructor calls (§12.1, §12.4). These techniques were first discussed 
for CH in Bjame Stroustrup: Operator Overloading for C++, Proc. IFIP WG2.4 
Conference on System Implementation Languages, September 1984. 


12.1.1c Function Return Values 


Consider a class Matrix with an addition operator and only the default assign- 
ment operator. 


class Matrix { 
IEE nee 
friend Matrix operator+(const Matrix&, const Matrixé&); 
}; 


When this operatort is used 
ml = m2 + m3; // ml, m2, and m3 are of type Matrix 


a temporary is generated to hold the result of m2+m3, and this temporary is then 
assigned to m1. 

Consider first the explicit assignment itself. The assignment can be eliminated 
only by constructing the result of m2+m3 directly in m1. This can be done only if 
the overwriting of the old value of m1 was equivalent to creating a new Matrix 
object and copying that into m1. This would occur only if Matrix assignment 
preserved the default semantics and the matrices m1, m2, and m3 have nonoverlap- 
ping representations. For example, eliminating the assignment when m1 and m2 are 
the same object could lead to trouble unless it was known that the code in the addi- 
tion operator worked correctly given such aliasing. A compiler typically does not 
have enough information to perform such optimizations. On the other hand, for 
initializations such as 


Matrix ml = m2 + m3; 


it is trivial to avoid using an extra temporary object for the result of the addition. 

One way of doing this is to compile functions retuming an object of class 
Matrix into a function with the address of an object in which to construct the 
retum object as an extra argument. Thus, the function 


Matrix operator+(const Matrix&, const Matrix&); 
can be compiled into the equivalent of a function with three pointer arguments. 


void matrix_add( ; 
Matrix* result, /* added by compiler */ 
Matrix* argl, 
Matrix* arg2 

i 


so the initialization 
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Matrix ml = m2 + m3; 
generates code like this: 

matrix_add(&m1, &m2, &m3) ; 
whereas the assignment 

ml = m2 + m3; 


must protect against aliasing and generates code like 


struct Matrix temp; /* no implicit initialization */ 
matrix _add(&temp, &m2, &m3); 
ml = temp; 


It is usually a good idea to define operations such as += and *= for arithmetic 
classes. Their use completely bypasses the introduction of temporaries since they 
by definition operate on a specific object, and aliasing is easy to manage in the 
code of the operations. For example, 


Matrix& Matrix::operator+=(const Matrix& a) 
{ 

// add a to *this 

return *this; 


} 


Now consider the definition of the addition operation. It would typically look 
like this: 


Matrix operator+(const Matrixé al, const Matrixé& a2) 


{ 
Matrix sum; 
// add al and a2 and place result in sum 
return sum; 

} 


Here a straightforward implementation will initialize sum to some default value and 
fill it with the correct retum value. Then the return statement will copy sum 
into a temporary using Matrix (const Matrix&). 

A smarter implementation will note that the local variable sum is redundant and 
eliminate it by using the object pointed to by result instead. In other words, the 
generated code will look something like this: 
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void matrix _add( 
Matrix* result, /* added by compiler */ 
Matrix* argl, 
Matrix* arg2 


J 

{ 
// construct *__result 
// add al and a2 and place result in *__result 
return; 

) 


Note that the result object still needs to be constructed before it can be filled. 
The construction of objects such as matrices can be inexpensive, but isn’t always. 
Writing the definition of operator+() slightly differently eliminates the 
apparently redundant construction of sum to a default value. 


Matrix operator+(const Matrix& al, const Matrixé& a2) 


{ 
Matrix sum = al; 
sum += a2; 
return sum; 

} 


This allows the compiler to generate close to optimal code. 


void matrix add( 
Matrix* result, /* added by compiler */ 
Matrix* argl, 
Matrix* arg2 


) 

{ 
// construct * result as a copy of al 
// add a2 to *__result 
return; 

} 


For less clever implementations, better code is often generated when the return 
expression is a constructor call. For example, an overloaded operator+ (§13 
and §13.4) for class complex might be defined to add two complex values 
without use of an explicit temporary variable. 


complex operator +(complex al, complex a2) 


{ 


return complex(al.reta2.re, al.imta2.im); 


} 


Code like this might be generated: 


i 
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void complex_add(complex* __ result, complex al, complex a2) 
{ 


__result->re = al.re + a2.re; 
__result->im = al.im + a2.im; 
} 


Inlining would complete the optimization of complex addition. 


12.1.2c Inline Functions 


Where a function call is implemented as a subroutine call, some amount of copying 
is necessary 10 pass arguments and retum values. When inlining is used such 
copies can be avoided where doing so does not involve side effects beyond the 
calls of constructors, destructors, and copy operations. In essence, the local copies 
of function arguments can be treated as temporary objects and sometimes elim- 
inated. For example, 


inline int putc(char x, FILE* p) 
í 
return --p->_cnt>=0 
? int (*p->_ptr++=unsigned (x) ) 
: _flsbuf (unsigned (x),p); 


void f(char* buf, FILE* f) 
{ 
putc(’a’,f); 
putc(*buft+, f); 
} 


Since the first call of putc does not involve side effects on its arguments, a simple 
expansion suffices, whereas the side effect on the first argument of the second call 
requires the introduction of a temporary. The generated code might look something 
like this: 


void f(char* buf, FILE* f) 
í 
// putc(’a’,f) 
--f->_cnt>=0 
? int (*f->_ptr++=unsigned(‘a’)) 
: _flsbuf (unsigned(’a’),f); 


// putc(*buftt, f) : 

char temp = *buf++; 

--f->_cnt>=0 
? int (*f->_ptr++=unsigned (temp) ) 
: _flsbuf (unsigned (temp), f); 
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12.2c Access Control and Special Functions 


Access control is applied to special member functions exactly as it is to other 
member functions. This can be used to control the availability of the operations 
implemented using the special member functions. For example, one could restrict 
copying of objects of a class X to be done only by members and friends of class X 
like this: 
class X { 
// Objects of class X cannot be copied 


// except by members and friends of X 
void operator=(X&); 


X (XE); 
Piet 
public: 
X (int); 
// 
Fz 
void f() { 
X a(l); 
X b= a; // error: X::X(X&) private 
b= a; // error: X::operator=(X&) private 
} 


Both explicit and implicit copy operations are affected by this, so even argument 
passing and value retum can be prevented for objects of a given class. For exam- 
ple, 


X £(X a) 
{ 
return a; // error: X::X(X&) private 
} 
void g() 
{ 
X a=0; 
f(a); // error: X::X(X&) private 
} 


Constructors and destructors obey access rules exactly as other functions do. 
They may be declared private or protected. y 

Declaring all a class’s constructors private has the effect that only static 
members of that class, friends of that class, or member functions, invoked through 
existing objects of the class, may create objects of the class type; declaring 4 
class’s constructors protected allows friends of the class and members and friends 
of classes derived from that class to create objects of the class type. Thus, making 
all a class’s constructors private or protected will disallow static (global) allocation 
of objects of the class and restrict the use of automatic (stack) objects to member 
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and friend functions. For example, 


class X { 
private: 
X()7 
public: 
void* operator new(size t); 
X* makeX() { return new X; } 
}; 


X a; // illegal; constructor is private 


void g(X* p) { 


s Dy // illegal 
X* c = new X; // illegal 
X* d = p->makeX(); // fine; 


} 


Restricting the access to a class’s constructors has the effect of restricting use of 
the new operator for objects of the class type, even if the new operator is declared 
public, because new implicitly calls a constructor. 

Interestingly, making a destructor private or protected also has the effect of 
disallowing automatic and static allocation of objects of that class type because 
such objects could never be destroyed. If a class’s destructor is private, only 
member and friend functions of that class may destroy objects; if the destructor is 
protected, only member and friend functions of the class or of classes derived from 
it may destroy objects. For example, 


class X { 
private: 
~X(); 
public: 
void elim() { delete this; } 
M3 


X a; // illegal, destruction cannot be done 


void g() { 
X b; // illegal, destruction cannot 
// be done 
X* p = new X; // fine, but object might never 
// go away 
delete p; // error: g() is neither friend 
// nor member 
p->elim(); // fine 
} 


Objects of a class for which access to the destructor is restricted can be allocated 
on the free store, as in g() above, but delete cannot be called for such objects. 


306 Special Member Functions Chapter 12 


Restricting the access to a class's destructor restricts use of the delete operator 


on operands of the class type, even if the delete operator is declared public, 
because delete implicitly calls the destructor. 


12.3c Summary of Member, Friend, and Special Functions 


The table below summarizes the characteristics of constructors, destructors, conver- 
sion functions, operator functions, and other member and friend functions. 


























generated 


can be | can have member 
virtual | return type or friend 


by default 





constructor member yes 
destructor member yes 
conversion member no 
= member yes 
() member no 
[] member no 
=> member no 
op= either no 
new static member | no 
delete static member | no 
other operator either no 


other member 
friend 


member 
friend 
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Overloading 








This chapter gives the syntax and semantics of operator and function overload- 
ing. Overloading allows multiple functions with the same name to be defined 
provided their argument lists differ sufficiently for calls to be resolved. By over- 
loading operators, the programmer can redefine the meaning of most C+ opera- 
tors (including function call (), subscripting [], assignment =, address-of &, 
and class member access ->) when @t#east one operand is a class object. 


13 Overloading 


When several different function declarations are specified for a single name in the 
same scope, that name is said to be overloaded. When that name is used, the 
correct function is selected by comparing the types of the actual arguments with the 
types of the formal arguments. For example, 


double abs (double); 
int abs(int); 


abs (1); // call abs (int); 
abs (1.0); // call abs (double); 


Since for any type T, a T and a T& accept the same set of initializer values, func- 
tions with argument types differing only in this respect may not have the same 
name. For example, 


int f(int i) 
{ 

//. 
} 
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int f(int&é r) // error: function types 
// not sufficiently different 
{ 
// 
) 


Similarly, since for any type T, a T, a const T, and a volatile T accept the 
same set of initializer values, functions with argument types differing only in this 
respect may not have the same name. It is, however, possible to distinguish 
between const T&, volatile T&, and plain T& so functions that differ only in 
this respect may be defined. 


m Functions that differ only in these ways accept the same set of initializer values, 
but they don't accept the same set of initializers. Consider 


void fl(int); 
void f2(int&); 
void f£3(const inté&); 


void g() 
{ 
£1(2.2); // ok 
£2(2.2); // error: temporary needed to 
// initialize nonconst reference 
£3'(252))5 // ok (temporary used) 
) 


Here, the value 2.2 is an acceptable value for initializing an int. The floating 
point constant 2.2 will be truncated to the integer value 2 (§4.4). Where a refer- 
ence is used as the argument type, however, a temporary variable is needed to hold 
that integer. Using such a temporary is acceptable only for const references 
(§8.4.3). 

As mentioned (§4.1), relying on implicit conversions from double to int is 
poor style because they might — as in the example above — change the value. Com- 
pilers can help the programmer avoid surprises by warning about such conversions. 

If a user really wants to call £2() with the value 2.2, an explicit variable of 
type int must be introduced. 

void h() 
{ 
int a = int (2.2); 
£2 (a); // ok 


o 


Similarly, it is possible to distinguish between const T*, volatile T*, and 
plain T* so functions that differ only in this respect may be defined. 
Functions that differ only in the retum type may not have the same name. 
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m Consider 


X operator+(const Xé, const Y6); 
Y operatort+(const X4, const Y&); // error: function types 
// differ only in return 
// type 
void f(X a, Y b) 
{ 
X rl = atb; // error: ambiguous 
Y r2 = atb; // error: ambiguous 
} 


Here, it is obvious to the human reader that r1 should be initialized by a call of the 
first operator+ and r2 by a call of the second. In general, however, it is not that 
simple for humans or compilers to determine what the programmer really meant. 
Further, allowing overloading based on the retum type would invalidate the desirable 
property that C+ expressions can be analyzed bottom up looking at only a single 
operator and its operands at a time. O 


Member functions that differ only in that one is a static member and the 
other isn’t may not have the same name (§9.4). 

A typedef is not a separate type, but only a synonym for another type 
(§7.1.3). Therefore, functions that differ by typedef ‘‘types’’ only may not have 
the same name. For example, 


typedef int Int; 
Void {int A-A of van Ff} 
void f(int) i) {77% s 2/7 } // error: redefinition of f 


Enumerations, on the other hand, are distinct types and can be used to distinguish 
overloaded functions. For example, 


enum E {a}; 
void f(int i) { /* ... */ } 
void f(E i) E M ort ak Ae 


Argument types that differ only in a pointer * versus an array [] are identical. 
Note that only the second and subsequent array dimensions are significant in argu- 
ment types (§8.2.4). 


f (char*); 


f£(char[]); // same as f£(char*); 
f£(char(7)); // same as f£(char*); 
f (char[9]); // same as £(char*); 


g(char(*) [10}); 

g(char[5}[10})); // same as g(char(*) [10]); 
g(char[7][10]); // same as g(char(*) [10]); 
g(char(*)(20]); // different from g(char(*) (10]); 
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m Note that char, unsigned char, and signed char are distinct types, so six 
distinct functions are declared here: 


h(char); 
h(unsigned char); 
h(signed char); 


h(char*); 
h (unsigned char*); 
h(signed char*); 


13.1 Declaration Matching 


Two function declarations of the same name refer to the same function if they are 
in the same scope and have identical argument types (§13). A function member of 
a derived class is not in the same scope as a function member of the same name in 
a base class. For example, 


class B { 
public: 

int. £(int)); 
}; 


class D : public B { 
public: 

int f(char*); 
}; 


Here D: : f (char*) hides B::f (int) rather than overloading it. 


void h(D* pd) 
{ 
pd->f (1); // error: 
// D::f(char*) hides B::f(int) 
pd->B::f (1); // ok 
pd->f ("Ben"); // ok, calls D::f 
} 


A locally declared function is not in the same scope as a function in file scope. 


int f(char*); 
void g() 
{ 
extern f(int); 
f("asdf"); // error: f(int) hides f(char*) 
// so there is no f(char*) in this scope 
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m One might consider ignoring scope issues when resolving overloaded functions; 
that is, consider every function that would be in scope had it not been hidden by a 
name in an enclosed scope. This, however, would lead to surprises when an 
unsuspected function was invoked by a call. For example, 


class X1 { 
public: 

void flint); 
Me 


// chain of derivations X(n) : X(n-1) 


class X9 : public X8 í 
Public: 

void f(double); 
7 


void g(X9* p) 
{ 

p->£(2); // X9::f() or X1::f() 
} 


Unless the programmer has an unusually deep understanding of the program, the 
assumption will be that p->f (2) calls X9::£() — and not X1::f() declared 
deep in the base class. Under the G+ rules, this is indeed the case. 

Had the rules allowed X1::f£(int) to be chosen as a better match, uninten- 
tional overloading of unrelated functions would be a distinct possibility. In general, 
protection against accidental overloading is not easy for a compiler to provide, but 
see §10.2 for a discussion of how it might be handled for virtual functions. Virtual 
functions — which are by definition meant to be defined, overridden, called at dif- 
ferent levels of a class lattice, and so on — are the ones for which these problems 
most naturally occur. If the intent really were to call X1::£(), the declaration of 
X9 can be modified to ensure that. 


class X1 { 
public: 

void f(int); 
}; 


// chain of derivations X(n) : X(n-1) 


class X9 : public X8 { 
public: 

void f{double); 

void f(int i) { X8::fl(i); } 
}; 


void g(X9* p) 
{ 
p-f (2); // calls X1::f{int) indirectly 


J 
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m Allowing overloading across scopes would be particularly dangerous for functions 
written to modify the total state of an object in some way. For example, 


struct B { 
IE OBS 
void operator=(int i); 
B(int i); 

Me 


struct D: DB 
PE ROE 
}; 


void f() 

{ 
Dx=1; // error (fortunately) 
Times 
x = 2; // error (fortunately) 


) 


Had that initialization and assignment been allowed, only the B part of x would have 
been initialized and assigned to. For most classes such a partial initialization and 
update would lead to nasty surprises. O 


Different versions of an overloaded member function may be given different 
access rules. For example, 


class buffer { 
private: 
chat* p; 
int size; 


protected: 
buffer(int s, char* store) { size 


// 


s; p = store; } 


public: 
buffer (int s) { p = new char[size = s]; } 
IME Aes 

}e 


13.2 Argument Matching 


A call of a given function name chooses, from among all functions by that name 
that are in scope and for which a set of conversions exists so that the function 
could possibly be called, the function that best matches the actual arguments. The 
best-matching function is the intersection of sets of functions that best match on 
each argument. Unless this intersection has exactly one member, the call is illegal. 
The function thus selected must be a strictly better match for at least one argument 
than every other possible function (but not necessarily the same argument for each 
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function). Otherwise, the call is illegal. 


@ The details of what makes a “*best-matching sequence’ are described below as are 
details of how to consider arguments for overloaded operators and member functions. 
For now, consider an exact match better than any conversion and an int to 
double conversion better than any user-defined conversion. We can then examine 
the handling of multiple arguments in isolation. 

The basic principle for handling overloaded function calls with more than one 
argument is to look at each argument separately. If one function provides a better 
than or equal match for every argument and provides a strictly better match than all 
other functions for at least one argument, then it is called; otherwise the call is an 
error. 

Consider 


class X { public: X(int); J; 
class Y {); 


void f£(X,int); 
void f£(X,double); 
void f(Y, double); 


void g() { £(1,1); ) 


First f (Y, double) is excluded because there is no conversion from int to Y. 
Then the sets of best matches can be calculated for each argument, as follows: 


set for lst argument: { £(X,int) £(X,double) } 
set for 2nd argument: { £(%,int)\} 


where the conversion int to X defined by X” s constructor is used in all three cases. 
The intersection of these two sets is £(X,int), so the resolution of the call 
f£(1,1) is £(X(1),1). The identical conversions X (1) canceled themselves out 
so the function was selected on the basis of second argument. 

As an example of an ambiguity, consider 


struct X { X(int); J}; 


void f(X,int); 
void f(int,X); 


void g() { £(1,1); } // error: ambiguous 
Here the sets of best matches are 


set for lst argument: { £(int,X) } 
set for 2nd argument: { £(X,int) } 


Since the intersection of these sets is empty the call f (1, 1) is ambiguous. 
Note that if there are two types that can be converted into each other, all calls 
involving an argument of each will fail. 





i 
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f (int, double); 
f (double, int); 


void g() ( f(1,1); } // error: ambiguous 
The sets 


set for Ist argument: { £(int,double) } 
set for 2nd argument: { f£(double,int) } 


have an empty intersection, so the call f (1, 1) is ambiguous. 
It follows that the binary operations for built-in types do not obey these ambi- 
guity rules. For example, 


1+1.0 


would be ambiguous. The explicit rules in §4.5, however, resolve this to a floating 
point addition. The problem with the (C and C+) rules for conversion of arithmetic 
types is that a value of any arithmetic type can implicitly be converted into any other 
arithmetic type. 

Up to this point we have not used the rule that the best-matching function must 
provide not only a match that is better than or equal to the matches of all other func- 
tions for each argument, but also must provide a match that is strictly better for at 
least one argument. Here is an example where that rule is necessary to avoid an 
anomaly: 


struct A [}); 

struct B : A {)}; 

struct C {}; // unrelated 
Struct D : B, Ci {]}/ 


void £(C*,C*); 
void f(A*,B*); 


D* pd; 
void g() 
{ 


f (pd, pd); // error: ambiguous 
} 


The best-match sets are 


set for lst argument: { £(C*,C*) £(A*,B*) } 
set for 2nd argument: { £(C*,C*) £(A*,B*) } 


The intersection has two members, so the call f (pd, pd) is ambiguous. Now add a 
third function. 
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void £(C*,C*); 
void f£(A*,B*); 
void f(B*,A*); 


void gg() 
í 

f (pd, pd); // still ambiguous 
} 


A conversion of a D* to a B* is better than the conversion of D* to A*, so we get 
the best-match sets: 


set for lst argument: t £(C*,C*) £(B*,A*) } 
set for 2nd argument: { £(C*,C*) £(A*%,B*) } 


The intersection has only one member £(C*,C*). The match for £(C*,C*), 
however, is not strictly better than the alternatives for any argument so the call is 
ambiguous. Without the rule requiring that a function must be strictly better for at 
least one argument we would have been required to call £(C*,C*). That would 
have implied that by adding a function declaration the programmer could resolve an 
ambiguity so that one of the original functions would have been called. That ano- 
maly does not seem to be a desirable property. O 


m There used to be a rule stating that ‘‘a call needing only standard conversions is 
preferred over one requiring user-defined conversions.’ The origin of this rule was 
an attempt to speed up compilation by reducing the number of possibilities the com- 
piler has to examine. It is unclear whether this was ever a significant improvement. 
That rule predated the intersection rule and resolved some examples that would oth- 
erwise have been ambiguities. For example, 


struct complex { complex(double); }; 


void h(int, complex); 
void h(double, double) ; 


void hh() 
{ 
h(3,4); // used to be ok: h(double(3),double(4)) 
// now ambiguous 
} 


Users considered the call above ambiguous, however, despite the opinions of the 
manual and the compiler, and were surprised by the resolution. Worse, by adding an 
argument requiring a user-defined conversion, such calls could become ambiguous. 


void h(int, complex, complex = 0); 
void h(double, double, complex = 0); 
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void hh() 
{ 


Chapter 13 


h(3,4); // used to be ok: h(double(3),double(4)) 


// now ambiguous 
h(3,4,0); // ambiguous 


For purposes of argument matching, a function with n default arguments 
(§8.2.6) is considered to be n+/ functions with different numbers of arguments. 


m That is, for argument matching purposes 
int f(int a, int b = 0); 
is equivalent to 


int f(int a, int b); 
inline int f(int a) ( return f(a,0); } 


This is, in fact, an elegant way of implementing default arguments. 


default arguments can cause ambiguities. For example, 


int £(); 
int f(int i = 1); 


void g() 
{ 
£(11); // fine 
£(); // error: ambiguous: f() or f(1) 


It implies that 


For purposes of argument matching, a nonstatic member function is considered 
to have an extra argument specifying the object for which it is called. This extra 
argument requires a match either by the object or pointer specified in the explicit 
member function call notation (§5.2.4) or by the first operand of an overloaded 
operator (§13.4). No temporaries will be introduced for this extra argument and no 


user-defined conversions will be applied to achieve a type match. 


m For example, 
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class X { 
public: 

void f(); 
}; 


class Y { 
public: 

operator X(); 
Mi 


void g() 
{ 

Y a; 

a.f(); // error 
} 


The conversion is not tried, so the interpretation 
(a.Y::operator X()).£(); 


is not used. O 


Where a member of a class X is explicitly called for a pointer using the -> 
operator, this extra argument is assumed to have type const X* for const 
members, volatile X* for volatile members, and X* for others. Where the 
member function is explicitly called for an object using the . operator or the func- 
tion is invoked for the first operand of an overloaded operator (§13.4), this extra 
argument is assumed to have type const X& for const members, volatile X& 
for volatile members, and X& for others. The first operand of —>* and .* is 
treated in the same way as the first operand of -> and ., respectively. 

An ellipsis in a formal argument list (§8.2.5) is a match for an actual argument 
of any type. 

For a given actual argument, no sequence of conversions will be considered that 
contains more than one user-defined conversion or that can be shortened by delet- 
ing one or more conversions into another sequence that leads to the type of the 
corresponding formal argument of any function in consideration. Such a sequence 
is called a best-matching sequence. 

For example, int->float—double is a sequence of conversions from int 
to double, but it is not a best-matching sequence because it contains the shorter 
sequence int—double. 


m Consider also, 


struct foo { operator char(); }; 


struct ostream { 
ostream& opérator<<(char); 
ostream& operator<< (double); 
}; 
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foo x; 
ostream cout; 


main() 
{ 

cout << x; // call ostream: :operator<<(char) 
) 


The Sequence foo-char is shorter than foo-char-double, so 
Ostream: :operator<< (char) is chosen. O 


Except as mentioned below, the following trivial conversions involving a type T 
do not affect which of two conversion sequences is better: 


from: to: 

T Té 

T6 T 

T() T* 

T(args) (*T) (args) 
T const: T 

T volatile T 
T* const T* 
T* volatile T* 


Sequences of trivial conversions that differ only in order are indistinguishable. 
Note that functions with arguments of type T, const T, volatile T, T4, 
const T&, and volatile Té accept exactly the same set of values. Where 
necessary, const and volatile are used as tie-breakers as described in rule [1] 
below. 

A temporary variable is needed for a formal argument of type T& if the actual 
argument is not an Ivalue, has a type different from T, or is a volatile and T 
isn’t. This does not affect argument matching. It may, however, affect the legality 
of the resulting match since a temporary may not be used to initialize a non-const 
reference (§8.4.3). 

Sequences of conversions are considered according to these rules: 

[1] Exact match: Sequences of zero or more trivial conversions are better than 

all other sequences. Of these, those that do not convert T* to const T*, 
T* to volatile T*, T& to const T&, or T& to volatile T& are better 
than those that do. 

[2] Match with promotions: Of sequences not mentioned in [1], those that con- 
tain only integral promotions (§4.1), conversions from float to double, 
and trivial conversions are better than all others. 

[3] Match with standard conversions: Of sequences not mentioned in [2], those 
with only standard (§4.1, $4.2, §4.3, §4.4, §4.5, §4.6, §4.7, §4.8) and trivial 
Conversions are better than all others. Of these, if B is publicly derived 
directly or indirectly from A, converting a B* to A* is better than converting 
to Void* or const void*; further, if C is publicly derived directly oF 
Indirectly from B, converting a C* to B* is better than converting to A* and 
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converting a C& to B& is better than converting to A&. The class hierarchy 
acts similarly as a selection mechanism for pointer to member conversions 
(§4.8). 

[4] Match with user-defined conversions: Of sequences not mentioned in [3], 
those that involve only user-defined conversions (§12.3), standard (§4) and 
trivial conversions are better than all other sequences. 

[5] Match with ellipsis: Sequences that involve matches with the ellipsis are 
worse than all others. 


w Why these rules? Wouldn't simpler rules do? Several issues are involved. The 
aim is to allow overloading to be used effectively and safely; that is, to allow as 
many reasonable distinctions between types as possible while still catching ambigui- 
ties. The degenerate case, that of having two functions taking unrelated arguments, 
leaves each function with exactly the same semantics as it had without overloading. 

The effects of overloading are independent of the order of function declarations. 
Adding a new declaration should not affect existing calls in surprising ways, but it 
should be able to affect them in reasonable, predictable ways: consider adding a 
function declaration that provides an exact match for a call — to eliminate a conver- 
sion. Furthermore, the standard conversion and promotion rules (of C and C++) must 
be preserved when overloading is used — because the programmer does not neces- 
sarily know when overloading is happening. 

Several rules exist to limit the number of ambiguities detected. The C mules 
allow all arithmetic types to be freely converted to each other. The distinctions 
among different types of conversion in rules {1}, [2], and [3] prevent calls of func- 
tions involving arithmetic types from degenerating into a mess of unavoidable ambi- 
guities. The rule limiting to one the number of acceptable user-defined conversions 
has a similar effect and also serves to avoid incomprehensible resolutions. Users can 
help with the resolution of a call by specifying explicit conversions. 

The rules for overloading resolution have changed over time. The main motiva- 
tion for the changes has been to eliminate order dependencies and to allow the detec- 
tion of more ambiguities. The general philosophy is that any dependence of declara- 
lion order is undesirable because it can lead to subtle ambiguities. Different versions 
of an overloaded function can be included from different header files; the order of 
overloaded function declarations is generally neither known by users, nor under their 
control. Similarly, a user can explicitly resolve a call that is deemed ambiguous, but 
if a call has been resolved in an unexpected way, much time can be lost looking for 
a run-time error. Another change has been to allow sensitivity for more types, such 
as being able to distinguish float and double for programmers on machines sup- 
porting both single and double precision floating point anthmetic. 

The following section presents a series of examples illustrating the rules above. 
First the five rules are illustrated in order, then examples of resolutions of calls with 
multiple arguments are presented, and finally examples involving default arguments 
and the ellipsis are shown. To ease reference the rules have been repeated. O 

[1] Exact match: Sequences of zero or more trivial conversions are better than 
all other sequences. Of these, those that do not convert T* to const T*, 
T* to volatile T*, T& to const T&, or T& to volatile T& are better 


than those that do. 
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m This is the rule that makes CH overloading sensitive to the type distinctions ordi- 
narily erased by the (C and C++) integral promotion rules (§4.1) and rules for promo- 
tion of floating types (§4.3). 

Consider 


void f (char); 
void ff{int); 

void f£ (unsigned) ; 
void f(long); 


void g() 

{ 
a A (Moka J // call f(char) 
f (lu); // call f(unsigned) 
£(1); // call flint) 
£(1L); // call f{long) 


} 


Note that the type of the character constant ’c’ really is char. 
Similarly, 


void f(float); 
void f(double); 
void f(int); 


void g() 

{ 
£(1.0); // call f (double) 
£(1.0F); // call f(float) 
SA eN // call f{int) 

} 


It is possible to define functions that differ only in const in a pointer or refer- 


ence. 


void f(char*); 
void f(const char*); 
void f2(char*); 
void £3(const char*); 


void g(char* pc, const char* pcc) 


{ . 
f(pce); 7/ call £(char*) 
f(pcec);  // call f(const char*) 
£2 (pc); 4/ call £2(char*) 
f2(pcc); // error: cannot initialize ‘char*’ 
// with ‘const char*’ 
£3 (pc); // call f£3(const char*) 
£3(pec); // call £3(const char*) 
} 


In other words, ‘‘constness’’ acts as a tie-breaker where needed but does not oe 
argument matching otherwise. This is especially important for const objects an 


f 
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const member functions. 


class X { 

public: 
void £() const; 
void f(); 
TE oss 

H; 


void g(const X& a, X b) 

{ 
af (); // calls X::£() const 
b.f(); // calls X:ż£() 

} 


The usual array-to-pointer conversion takes place. 


void f(char*); 
void g() 
{ 
char v{10]; 
char’ p = v; 
fiv): // call f(char*) 
fip); // call f(char*) 


o 


[2] Match with promotions: Of sequences not mentioned in [1], those that con- 
tain only integral promotions (§4.1), conversions from float to double, 
and trivial conversions are better than all others. 


m This rule exists to allow promotions to be preferred over standard conversions. 
For example, 


void f(int); 
void f£(double); 


void g() 
í 
short aa = 1; 


float ff = 1.0; 


f(aa); // call f(int) 
f£(ff); // call f£(double) 
) 


Without this rule, the calls would be ambiguous because a short can be converted 
to either an int or a double, and a float can be converted to either an int or a 
double. 

The distinction between ‘‘exact match’’ and ‘‘match with promotions’’ can be 
used to distinguish between integer types and between floating types. For example, 
enumerators are of the type of their enumeration (§7.2) and can be used in over- 
loaded function calls. 
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enum e { A, B ) ee; 
enum { A2, B2 }; 


void ffint); 
void f(e); 


void g() 
{ 

£(0); // call f(int), 0 is an int 

f(A); // call ffe) 

f(A+1); // call f(int), A is promoted to int 

// before the addition 

f(ee); // call f(e) 

£(A2); // call f(int), A2 is promoted to int 
} 


Note that integral promotions (§4.1) are implementation dependent. 


int ffint); 
int f (unsigned); 


void g(unsigned short us) 
{ 
int i = £f(us); 


) 
Here f(int) is called if sizeof(short)<sizeof(int); otherwise 
f (unsigned) is called. This could lead to nasty surprises when a program is 
ported to a new implementation, but the rule is necessary to avoid an incompatibility 
with the ANSI C integral promotion rules (§4.1). O 


[3] Match with standard conversions: Of sequences not mentioned in [2], those 
with only standard (§4) and trivial conversions are better than all others. Of 
these, if B is publicly derived directly or indirectly from A, converting a B* 
to A* is better than converting to void* or const voids; further, if C is 
publicly derived directly or indirectly from B, converting a C* to B* is 
better than converting to A* and converting a C& to B& is better than con- 
verting to A&. The class hierarchy acts similarly as a selection mechanism 
for pointer to member conversions (§4.8). 


m This rule ensures that ambiguities between standard conversions are caught and 
that all standard conversions are considered equal. For example, 


void f (char); 
void f£(float); 


void gf) 
{ 
f£(1); // ambiguous: f(char) or f(float) 
f(1L); // ambiguous: f(char) or f (float) 
} 


There was serious discussion of preferring value-preserving conversions tO 
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potentially value-destroying conversions beyond the distinction between promotions 
and conversions. Attempting to elaborate the overloading resolution to make it more 
‘natural’ failed for several reasons: What is value-destroying depends critically on 
the actual value, which must nor be considered in the overloading stage. Overload- 
ing resolution is based only on type. What is value-destroying depends critically on 
the implementation of the various dala types. What is value-destroying on one 
machine may be safe on another. For example, the conversion of a long to a 
float may -— or may not — be a value-destroying conversion. One 
implementation-dependent conversion rule was necessary to maintain ANSI C com- 
patibility, but even that is probably one too many. 

Another idea for improvement was to define a type lattice describing the accept- 
able conversions. Conversions between types that were close in the lattice would be 
better than conversions between types that were more distant. This was defeated by 
complexity, the implementation dependence of many C standard conversions, and the 
existence of several inherently value-destroying standard conversions (for example, 
double to int and int to char). Such conversions go the wrong way in any 
reasonable conversion lattice. 

Note that the use of references does not change the set of values accepted com- 
pared to their corresponding object types. 


void f(const charé&); 
void f(short); 


void g() 
{ 
A (of dat BS // call f(const charé&) 


const char ch = ‘c’; 
f(ch); // call f(const charé) 


short s = 3; 
f(s); // call f(short) 


£(3); // error: ambiguous 
// €(short) or f{const char&) ? 
) 


Here, a temporary variable is needed for the first call of £() because ‘c’ is a 
literal (of type char). On the other hand, a temporary may not be used to initialize 
a non-const reference, so a call may be determined to be an error after the selec- 
tion of a function. 


void f(char&); 
void f(short); 


void g() 
{ 
£('c") > // error: call f(chars), 
// requires temporary 
} 


Here, f (char&) is preferred to f (short) exactly as in the example above, but 
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since a temporary is required to hold ’c’ and the reference is not const, the call 
is not accepted. This does not lead to an otherwise legal call of f (short). 

Note that 0 is of type int so it is an exact match for an int argument but a 
match with standard conversions for arguments of types short, double, char*, 
and so on. For example, 


void f(char); 
void f (double); 


void gí) 

í 
f£(’a’); // call f(char) 
£(0); // error, ambiguous: f(char) or f£{double) ? 
£(1.0); // call f (double) 

J 


Rule [3] implies that a value-preserving conversion — a promotion — is preferred 
to a potentially value-destroying standard conversion. For example, 


void f(char); 
void f(int); 


void g(short s) 
{ 

f(s); // call f{int) 
} 


An inheritance hierarchy defines a preference order for the standard pointer and 
reference conversions (§4.6, §4.7). 


class A {}; 
class B : public A {}); 
class C : public B {}; 


void g(A*); 
void g(B*); 


Cice; 


void f{) 
{ 

g(&cc); // call g(B*) 
} 


In a sense, void* is the root of such hierarchies. 


void h(void*); 
void h(A*); 


void hh() 
{ 
h(gcc); // call h(A*) 
h(0); // error: ambiguous, h(void*) or h(A*)? 
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[4] Match with user-defined conversions: Of sequences not mentioned in [3], 
those that involve only user-defined conversions (§12.3), standard (§4) and 
trivial conversions are better than all other sequences. 


m Preferring a standard conversion to a user-defined conversion seems reasonable 
and is usually the right thing to do. In particular, it makes code that relies only on 
standard conversions (such as C code) immune to any added user-defined types. 
Preferring standard conversions to user-defined conversions occasionally masks 
ambiguities, though. In the following example, selecting the right choice is non- 


trivial: 
class Real { // high precision real numbers 
TT vows 
Real (double); // make a Real from a double 
Me 


double sqrt (double); 
Real sqrt (Real); 


void g(long 11) 
{ 


double d = sqrt (11); // call sqrt (double) 
) 


The compiler cannot determine the precision with which the user wants the square 
root calculated. The language is defined to prefer the standard conversion of the 
long 11 to a double over the user-defined conversion to a Real. In such cases 
some programmers would prefer an ambiguity error. O 


[5] Match with ellipsis: Sequences that involve matches with the ellipsis are 
worse than all others. 


m If the ellipsis is used, all type information vanishes and type checking is broken. 
Consequently, this possibility is taken only if all else fails: 


class Real { 

PE AOC 
public: 

Real (double); 
}; 


void f(int ...); 
void f(int, Real); 


void gf) 

{ 
f£(1,1); // call f(int, Real) 
f£(1,"Annemarie"); // f(int ...) 

} 


The ellipsis can also cause ambiguities. 


326 Overloading Chapter 13 


f(int); 

tlini Tees)? 

flint, chart ...); 

void gf) 

{ 
f£(1); // error, ambiguous: f(int) or flint .. 
£(1,2); // fine: f(int ...) 


f£(1,"asdf"); // fine: flint, char* ...) 
f£(1,"asdf",2); // fine: fint, char* ...) 


User-defined conversions are selected based on the type of variable being ini- 
tialized or assigned to. 


class Y { 
// 
public: 
Operator int(); 
operator double(); 
); 


void £(Y y) 

{ 
int i = y; // call Y::operator int () 
double d; 
d = y; // call Y::operator double () 


float f = y; // error: ambiguous 
} 


Standard conversions (§4) may be applied to the argument for a user-defined 
conversion, and to the result of a user-defined conversion. 


struct S { S(long); operator int(); }; 
void f(long), f(char*); 


void g(S), g(char*); 
void h(const S&), h(char*); 


void k(S& a) 


{ 
f(a); // £(long(a.operator int())) 
g(1); // g(S(long(1))) 
h(1); // h(S(long(1))) 

} 


If user-defined coercions are needed for an argument, no account is taken of any 
Standard coercions that might also be involved. For example, 


-) 


kes. 
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class x { 
public: 

x(int); 
}; 


class y { 
public: 

y (long) ; 
}; 


void f(x); 
void f(y); 


void g() 
{ 

£(1); // ambiguous 
} 


The call f (1) is ambiguous despite f (y (long (1) )) needing one more standard 
conversion than f (x (1) ). 

No preference is given to conversion by constructor (§12.1) over conversion by 
conversion function (§12.3.2) or vice versa. 


struct X { 
operator int(); 
}; 


struct Y { 
Y(X); 
}; 


Y operator+(Y,Y); 


void f(X a, X b) 
{ 
atb; // error, ambiguous: 
Fae operatort+(Y¥(a), Y(b)) or 
// a.operator int() + b.operator int() 


13.3 Address of Overloaded Function 


A use of a function name without arguments selects, among all functions of that 
name that are in scope, the (only) function that exactly matches the target. The tar- 
get may be 


an object being initialized (§8.4) 
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the left side of an assignment (§5.17) 

a formal argument of a function (§5.2.2) 

a formal argument of a user-defined operator (§13.4) 
a function return type (§8.2.5) 


Note that if £() and g() are both overloaded functions, the cross product of 
possibilities must be considered to resolve £(&g), or the equivalent expression 
f (g). 

For example, 


int f (double) ; 

int f (int); 

int (*pfd) (double) = &f; 

int (*pfi) (int) = &f; 

int (*pfe)(...) = &f; // error: type mismatch 


The last initialization is an error because no £() with type int(...) has been 
defined, and not because of any ambiguity. 

Note also that there are no standard conversions (§4) of one pointer to function 
type into another (§4.6). 


m The reason no implicit conversions are performed for pointer to function types is 
that allowing a conversion loosens the requirements on the types of arguments (as in 
the last initialization above) and would implicitly violate the guarantee that a func- 
tion will be called with arguments of the type it is declared to accept. A program- 
mer can, however, explicitly request such a potentially dangerous conversion for a 
function that has not been overloaded. 


int (*pfe)(...) = (int (*)(...))&g- // ok 


Naturally, it then becomes the programmer's responsibility to ensure that f() is 
called with arguments of the right type, in this case a single int. The opposite 
conversion 


int h(int ...); 
int (*p) (int,int) = &h; // error: type mismatch 


would be harmless in the sense that it increases the constraints on the arguments, but 
allowing it would not be worth the added complexity. 

Allowing it would also have a detrimental effect in that it would constrain imple- 
mentations to use fundamentally similar mechanisms to implement calls of functions 
for which the argument types are known and calls of varadic functions. This would 
be suboptimal since most calls are to functions with known argument types that can 
be implemented with less overhead than varadic functions. O 


In particular, even if B is a public base of D we have 


aa 
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D* £(); 
B* (*pl)() = &f; // error 


void g(D*); 
void (*p2) (B*) = &g; // error 


m Had these examples been allowed, we could — without using explicit type conver- 
sion — call g() with an argument that wasn't a D. 


void hl() 
{ 
B b; 
p2(&b); // p2 requires only a B* 


) 


Simply modifying the retum type would cause a more subtle problem if allowed. 
The function f () retums a pointer to a D, that is, a pointer to the beginning of a D. 
The base B may not be allocated at the beginning of the D. For example, 


class D : public A, public B { 
// The B might be 1000 bytes 
// from the beginning of the D 
J 


D* f() { return new D; } 


void h2() 

{ 
B* (*pl)() = &£; // error 
B* p = pl(); 

) 


There is no way for the compiler to know that it has to adjust the value of the 
pointer returned from a call through p1 to refer to the B sub-object of a D. 

This problem could be circumvented by generating pointer adjusting code at the 
point of the initialization of p1 and letting p1 point to that (see §10.3, §10.6). Such 
cleverness, however, seems excessive. O 


13.4 Overloaded Operators 
Most operators can be overloaded. 


operator-function-name; 
operator operator 
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operator: one of 


+ = * / % x & | 

! = < > += -= ote /= = 
^= &= = << >a >on. Gla == |! 
<= >= & || +t -- , ->* -> 


The last two Operators are function call (§5.2.2) and subscripting (§5.2.1). 
Both the unary and binary forms of 


+ - * & 
can be overloaded, 
m A scheme for the encoding of overloaded operator names is presented in §7.2.1. O 


The following operators cannot be overloaded: 


ae ous Ts 
nor can the preprocessing symbols # and ## (§16). 


m The reason for disallowing the overloading of ., .*, and :: is that they already 
have a predefined meaning for objects of any class as their first operand. Overload- 
ing of ?: simply didn’t seem worthwhile. O 


Operator functions are usually not called directly; instead they are invoked to 
implement operators (§13.4.1, §13.4.2). They can be explicitly called, though. For 
example, 


complex z = a.operator+(b); // complex z = atb; 
void* p = operator new(sizeof (int) *n); 


The operators new and delete are described in §5.3.3 and §5.3.4 and the 
rules described below in this section do not apply to them. 

An operator function must either be a member function or take at least one 
argument of a class or a reference to a class. It is not possible to change the pre- 
cedence, grouping, or number of operands of operators. 


m This implies, for example, that if operator™% is defined it must be defined as a 
member function taking one argument or as a global function taking two arguments. 
There is no unary or ternary form of ^ and no way of defining such. O 


The predefined meaning of the operators =, (unary) &, and , (comma) applied to 
Class objects may be changed. Except for operator=(), operator functions are 
inherited; see §12.8 for the rules for operator=(). 


m This implies that the meaning of operators applied to nonclass types cannot be 
redefined. The intent is to make Ch extensible, but not mutable. This protects the 
CH programmer from the most. obvious abuses of operator overloading, such as 
redefining + On integers to mean subtraction. 


+ Section 13.4 Overloaded Operators 331 


Note that — except for operator new() and operator delete () — there 
are no restrictions on the retum types of overloaded operators. 

It would be an obvious extension to allow users to define their own operators in 
addition to the built-in ones. 


wa! // exponentiation 

max 

min 

// // division with remainder stored in ‘__rem’ 
od // my multiplication 

+. // my addition 


This extension, however, would imply a significant extension of complexity of syn- 
tax analysis and an uncertain gain in readability. It would be necessary either to 
allow the user to specify both the binding strength and the associativity of new 
operators or to fix those attributes for all user-defined operators. In either case, the 
binding of expressions such as 


a = b**c**d; // (a**b)**c or at**(b**c) ? 


would be surprising or annoying to many users. It would also be necessary to 
resolve clashes with the syntax of the usual operators. Consider this, assuming ** 
and // to be defined as binary operators: 


a = a**p; // a**p OR a*(*p) 
a = a//p; 
*p = 7; // a = a*p = 7; maybe? 


oO 


Identities among operators applied to basic types (for example, ++a = at+=1) 
need not hold for operators applied to class types. Some operators, for example, 
+=, require an operand to be an lvalue when applied to basic types; this is not 
required when the operators are declared for class types. 


m It is, however, usually a good idea to use operator overloading to mimic conven- 
tional usage. It follows that operators, such as +=, that require lvalues for built-in 
types should be defined as member functions, thus in effect requiring the overloaded 
versions to accept only Ivalues as their first operand just as their built-in counterparts 
do. Similarly, operators such as +, that do not require lvalues for built-in types 
should be defined as global functions (often as friends) to allow standard and 
user-defined operators to be applied uniformly to both operands. 

Similarly, it is typically a good idea to maintain the usual equivalences between 
operators. For example if more than one of the operators —>, +, and [J are defined 
for a class V, one would expect v->m, (*v).m, and v[0].m to have identical 
values for all objects v of class V. O 


An overloaded operator cannot have default arguments ($8.2.6). 
Operators not mentioned explicitly below in §13.4.3 to §13.4.7 act as ordinary 
unary and binary operators obeying the rules of section §13.4.1 or §13.4.2. 
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m In particular, overloaded operators , and ->* obey exactly the same rules as other 
overloaded binary operators, such as ^ and $. O 


13.4.1 Unary Operators 


A prefix unary operator may be declared by a nonstatic member function (§9.3) 
taking no arguments or a nonmember function taking one argument. Thus, for any 
prefix unary operator @, @x can be interpreted as either x.operator@() or 
operator®@ (x). If both forms of the operator function have been declared, argu- 
ment matching (§13.2) determines which, if any, interpretation is used. 


m For example, 


struct B { 
int operator! (); 
gl O-; 

h; 


Struct D: B YaN Ié 


int operator! (D6); 


int f£(D& d) 
{ 


return !d; 
} 


calls ::operator! (D&) because calling B::operator! () would require a 
standard conversion of a D* to a B*, and 


int operator! (B&); 


int ff(B& b) 
{ 
return !b; // error: ambiguous 


) 


is obviously ambiguous given the definition of class B above. 

Note that the transformation of an operator application to an overloaded function 
is not context sensitive, so applying the operator within a class member function has 
the same resolution as the application outside. 


int D::g2() 

return !*this; // calls ::operator(D&) 
} 

int B::gl{() 

return !*this; // error: ambiguous 

} 
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See §13.4.7 for an explanation of postfix unary operators, that is, ++ and --. 


m Note that when the x.operator@() interpretation is used no user-defined 
conversions will be applied to x (§12.3). O 


13.4.2 Binary Operators 


A binary operator may be declared either by a nonstatic member function (§9.3) 
taking one argument or by a nonmember function taking two arguments. Thus, for 
any binary operator @, x@y can be interpreted as either x.operator@(y) or 
operator@ (x,y). If both forms of the operator function have been declared, 
argument matching (§13.2) determines which, if any, interpretation is used. 


m Note that when the x.operator@(y) interpretation is used no user-defined 
conversions will be applied to x (§12.3). O 


m When both forms of the operator function have been declared, ambiguity control is 
necessary. For example, 


class X { 
public: 

X operator+ (int); 
}; 


X operator+ (X,double); 


void g(X b) 
í 
X a; 
a = bł]; // call X::operator+t (int) 
a = b+1.0; // call ::operator+(X, double) 
a = btlL; // error: ambiguous 


D 


m Allowing only individual operators to be overloaded leaves the user with the 
minimal amount of specification and the compiler with a major optimization prob- 
lem. In particular, handling the problems of possible aliasing and minimization of 
the use of temporaries is usually not possible for compilers since they don’t know 
the semantics of the functions called to interpret the expressions containing over- 
loaded operators. O 


m It might be possible to let the user help the compiler generate better code by speci- 
fying what is to be done for common combinations of operations. For example, the 
two multiplications in 

Matrix a, b, c, d; 


POS mite 
a=b*e*td; 


might be implemented by a specially defined ‘‘double multiplication’’ operator 
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defined like this: 

Matrix operator * * (Matrix&, Matrix&é, Matrix&); 
that would cause the statement above to be interpreted like this: 

a = operator * * (b,c,d); 
In other words, having seen the declaration 

Matrix operator * * (Matrix&, Matrix&, Matrixé); 


the compiler looks for pattems of repeated Matrix multiplications and calls the 
function to interpret them. Patterns that are different or too complicated are handled 
using the usual (unary and binary) operators. 

This extension has been independently invented several times as an efficient way 
of coping with common pattems of use in scientific computing using user-defined 
types. For example, 


Matrix operator = * + ( 
Matrixé, 
const Matrixé, 
double, 
const Matrixé 

3 


for handling statements like this: 
a=b*1.7+d; 


This scheme would also allow the overloading of the ternary operator ?:. For 
example, 


operator?: (int,const X&,const Y&); 


void f(int i, X a, Y b) 


í 
int j = i?a:b; 


} 


13.4.3 Assignment 


The assignment function operator=() must be a nonstatic member function; it 
is not inherited (§12.8). Instead, unless the user defines operator= for a class X, 
operator= is defined, by default, as memberwise assignment of the members of 
class X. 


X& X::operator=(const X& from) 
{ 

// copy members of X 
} 
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m The assignment operator is the only operator function that is not inherited. 

Assignment has a useful and necessary generalization across all classes (memberwise 

copy; see §12.8). No other operator has that. Assignment resembles constructors 

and destructors more than it resembles operators such as + and +=. z 
Assignment must be a member function to avoid absurdities caused by defining 

an assignment operator after assignments of objects of a class have taken place. For 


example, 
class X ( 
Pi sinc 
}; 
void f() 
{ 
X a,b; 
// 
ā = b; // default meaning of assignment 
} 
X6 operator=(X&,const X6); // fortunately an error 
void g() 
{ 
X a,b; 
Ife gore 
a=b; // nonstandard meaning of assignment 


} 


Further problems could be created by providing different definitions of assignment in 
different files or even in different scopes within the same file. 


Assignment operators, such as +=, however, have no predefined meaning for 
class objects and can be defined as globa! functions. O 


13.4.4 Function Call 
Function call 
primary-expression (  expression-list.,, ) 


is considered a binary operator with the primary-expression as the first operand and 
the possibly empty expression-list as the second. The name of the defining func- 
tion is operator(). Thus, a call x(argl,arg2,arg3) is interpreted as 
x. operator () (argl,arg2,arg3) for a class object x. operator() must 
be a nonstatic member function. 


m Consider a class string, for manipulating strings of characters. 


class Substring; 
class String { 
AEE 
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Public: 
String(const char*); 
String& operator=(const Stringé&); 
String& operator=(const Substringé&); 
Substring operator() (int position, int length); 


IPERS 
Me 
class Substring ({ 
TE cere 
public: 


operator String(); 

String& operator=(const Strings); 

String& operator=(const Substrings); 
Mi 


With suitable definitions strings and substrings can be used like this: 


String month = "June"; 
month(2,2) = "ly"; // month becomes "July" 


Here the substring operator retums a Subst ring describing month (2, 2); that is, 
the last two characters of the value of String variable month. The assignment is 
then resolved to a call of Substring's assignment operator with the operand 
String("ly") to place ly in the part of month described by the substring 
month (2, 2) so month finally gets the value "July". 

Other common uses of overloaded function call operators are defining a call 
Operator for objects that act as functions (usually containing a pointer to a member 
function and a pointer to an object) and defining a subscript operator for genuinely 
multidimensional arrays. O 


13.4.5 Subscripting 
Subscripting 
primary-expression [ expression } 


is considered a binary operator. A subscripting expression x[y] is interpreted as 
x.operator[] (y) for a class object x. operator[] must be a nonstatic 
member function. 


m An operator[] function can be used to define subscripting for class objects. 
For example, 


Class String { 
1h foo” 

Public: 
String(const char*); 
charé operator[] (int); 
bh Ge 

Me 


Because the value retumed by String.operator[]() here is a charé, that 
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function can be used on either side of an assignment operator. For example, 


String ss = "asdf"; 
ss[1] = ss[3); 


The assignment is interpreted as 
ss.operator[]) (1) = ss.operator[] (3); 


Thus, the new value of ss is "afdf". 
The second argument (the subscript) of an operator[] function may be of 


any type. This allows popular types, such as associative arrays, to be defined with 
conventional notation. O 


13.4.6 Class Member Access 
Class member access using -> 
primary-expression -> primary-expression 


is considered a unary operator. An expression x->m is interpreted as 
(x.operator->())-—>m for a class object x. It follows that operator-—>() 
must retum either a pointer to a class or an object of or a reference to a class for 
which operator->() is defined. operator-—> must be a nonstatic member 
function. 


m Consider creating classes of objects intended to behave like what one might call 
“smart pointers’’ — pointers that do some additional work, like updating a use 
counter on each access through them. 


struct Y { int m; ); 


class Yptr { 
Y* p; 
// information 
public: 
Yptr(const char* arg); 
Y* operator->(); 
Me 


Yptr::Yptr(const char* arg) 

{ 
p= 0; 
// store away information 
// based on ‘arg’ 
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Y* Yptr::operator->() 
{ 
if (p) { 
// check p 


// update information 
} 


else { 
// initialize p using information 


} 
return p; 


} 


Class Yptr's -> operator could be used as follows: 


void f(Yptr y, Yptré yr, Yptr* yp) 
í 
int i = y->m; // y.operator->()->m 
i = yr->m; // yr.operator->()->m 
i = yp->m; // error: Yptr does not have 
// a member m 
) 


Class member access is a unary operator. An operator->() must retum 
something that can be used as a pointer. . 


Note that there is nothing special about the binary operator ->*. The rules in 
this section apply only to ->. O 


13.4.7 Increment and Decrement 


A function called operator++ taking one argument defines the prefix increment 
operator ++ for objects of some class. A function called operator++ taking two 
arguments defines the postfix increment operator ++ for objects of some class. For 
postfix operator++, the second argument must be of type int and the opera- 
tor++() will be called with the second argument 0 when invoked by a postfix 
increment expression. For example, 


class X { 
public: 
operatortt+(); // prefix +ta 
operatort++ (int); // postfix att 
}; 
void f(X a) 
{ 
+ta; // a.operatort+(); 
att; // a.operator++ (0); 


a.operatort+(); // explicit call: like +ta; 
a.operatort+(0); // explicit call: like att; 
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The prefix and postfix decrement operators ~~ are handled similarly, 


m Originally, C+ did not provide a way of specifying separate functions for prefix 
and postfix application of ++. A single operator++ was used to overload both, 
and no way was provided to distinguish which notation was used to trigger an invo- 
cation of an operator++(). The ability to distinguish prefix and postfix applica- 
tion of the unary increment operators has been vigorously requested by users for 
years. It was particularly desired by users who defined *‘smart pointer'’ types 
(§13.4.6). O 


m The choice of the one-argument version of operator++ for specifying prefix 
application and the two-argument version of operator++ for specifying postfix 
application is not random. All other unary operators are prefix and are overloaded 
by a function taking one argument. Since a member function must have the implicit 
this pointer as its first or only argument, operator++(int) must define the 
postfix version, 


class X { 
operator++(); // ++a, syntactically like !a 
operator++ (int); // a++0, syntactically like a+0 


); 
Similarly for global functions, 


class Y { 
friend operator++(Y&); // ++ta, like !a 
friend operatort+(Y&é&,int); // at++0, like a+0 
Me 


void g(Y a) 

í 
++a; // operatort++ (a); 
att; // operatort+(a,0); 
operator++ (a); // ++a; 
operator++ (a, 0); // att; 


} 


The notation a++3 is illegal (as is 3++a), but a. operator++ (3) is legal and the 
argument (in this case 3) will be passed. O 
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Templates 














A class template defines the layout and operations for an unbounded set of 
related types. For example, a single class template List might provide a com- 
mon definition for list of int, list of float, and list of pointers to Shapes. A 
function template defines an unbounded set of related functions. For example, a 
single function template sort () might provide a common definition for sorting 
all the types defined by the List class template. 


14 Templates (Experimental) 


The template design is experimental; it was first presented in Bjame Stroustrup: 
Parameterized Types for C++, Proc. USENIX CH Conference, Denver, October 
1988. 








t 
| 


Commentary 





The template design for parameterized classes and functions is experimental and is 
therefore described only in the commentary. Because in its final form it will 
belong in the reference manual, it is presented in manual style; embedded commen- 
tary is used just as in the manual proper. 


342 Templates Chapter 14 


14.1c Templates 


A template defines a family of types or functions. 


template-declaration: 
template < template-argument-list > declaration 


template-argument-list: 
template-argument 
template-argument-list , template argument 


template-argument: 
type-argument 
argument-declaration 


type-argument: 
class identifier 


The declaration in a template-declaration must declare or define a function or a 
class. 

A type-argument defines its identifier to be a type-name in the scope of the tem- 
plate declaration. 

Template names obey the usual scope and access control rules. 


m The template argument list cannot be empty. A template with an empty argument 
list would simply define a single class or function and is therefore redundant. O 


A template-declaration is a declaration. A template-declaration may appear only 
as a global declaration. 


m The template mechanism provides a way of providing general container types such 
as list, vector, and associative array where the specific type of the elements is left as 
a parameter. lt does so in a way that does not compromise the static type system 
and allows close to optimal run-time performance through macro expansion of defin- 
itions and inlining of function calls (§16.3, §7.1.2, §16.1). Inheritance can be used 
to achieve flexibility in a dimension that the template concept does not serve, and 
Vice versa. O 


m The restriction to global templates is stronger than necessary; some templates 
could be handled in some local and nested contexts. Some, however — such as a 
template for a function definition defined within a function — cannot, and a general 
and simple restriction seems more sensible than a detailed and possibly subtle list. O 


14.2c Class Templates 


A class template specifies how individual classes can be constructed much as a 
class declaration specifies how individual objects can be constructed, A vector 
class template might be declared like this: 
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template<class T> class vector { 


T* v3 
int sz; 
public: 


vector (int) ; 
T& operator[] (int); 
T& elem(int i) { return v[iJ; } 
// 
}; 
The prefix template <class T> specifies that a template is being declared and 
that a type-name T will be used in the declaration. In other words, vector is a 


parameterized type with T as its parameter. 
A class can be specified by a template-class-name: 


template-class-name: 
template-name < template-arg-list > 


template-arg-list: 
template-arg 
template-arg-list , template-arg 


template-arg: 
expression 
type-name 


A template-class-name is a class-name (§9). 

A class generated from a class template is called a template class, as is a class 
specifically defined with a template-class-name as its name; see §14.5. 

A template-class-name where the template-name is not defined names an unde- 
fined class. 

A class template name must be unique in a program and may not be declared to 
refer to any other template, class, function, object, value, or type in the same scope. 

The types of the template-args specified in a template-class-name must match 
the types specified for the template in its template-argument-list. 


m Specifying no restrictions on what types can match a type argument gives the pro- 
grammer the maximum flexibility. The cost is that errors — such as attempting to 
sort objects of a type that does not have comparison operators — will not in general 
be detected until link time (§7.2). Only then are both the template that defines the 
sort operation and the type of the elements to be sorted available. O 


Other template-args must be constant-expressions, addresses of objects or func- 
tions with external linkage, or of class members. An exact match (§13.2) is 
required for nontype arguments. 


m Nontype template arguments are restricted to values that can be compared at com- 
pile time. This allows static type checking involving the resulting types. O 
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For example, vectors can be used like this: 


vector<int> v1 (20); 
vector<complex> v2 (30); 


typedef vector<complex> cvec; // make cvec a synonym 
// for vector<complex> 
cvec v3(40); // v2 and v3 are of the same type 


v1(3]) = 7; 
v2[3] v3.elem(4) = complex(7,8); 


Here, vector<int> and vector<complex> are template classes, and their 
definitions will by default be generated from the vector template. 

Since a template-class-name is a class-name, it can be used wherever a class- 
name can be used. For example, 


class vector<Shape*>; 
vector<Window>* current_window; 


class svector : public vector<Shape*> { /* ... */ }; 


Definition of class template member functions is described in §14.6. 


m The syntax relying on the template keyword and the placement of the template 
arguments before the definition was chosen to make it as clear as possible when a 
template was defined and to ensure that type parameters were introduced lexically 
before their first use. 

This alternative notation was considered: 


class vector<class T> { 
Tny? 
Td eta 

de 


void sort<class V>(vector<V>&.v); 


It is terser and in some ways more consistent, in that template arguments always 
appear just after the template name. 

This notation, however, has no keyword to attract the attention of human readers 
and tools; it would compound the problems caused by C and C++ function declara- 
tions not starting with a specific keyword. Consider 


T& index<class T>(vector<T>&,int) { /* ... */ J}; 


Parsing this example requires unnecessary cleverness because the first use of the 
type parameter T occurs lexically before the declaration that makes it a type-name. 
The chosen syntax has no such problem. 


template<class T> T& index(vector<T>&é,int) { /* ... */ l; 
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14.3¢ Type Equivalence 


Two template-class-names refer to the same class if their template names are identi- 
cal and their arguments have identical values. For example, 


template<class E, int size> class buffer; 


buffer<char,2*512> x; 
buffer<char,1024> y; 


declares x and y to be of the same type, and 


template<class T, void(*err fct) ()> 
class list { /® 1e */ 0; 


list<int,éerror_handlerl> xl; 
list<int,&error_handler2> x2; 
list<int,éerror handler2> x3; 
list<char,&error handler2> x4; 


declares x2 and x3 to be of the same type. Their type differs from the types of 
xl and x4. 


I4.4c Function Templates 


A function template specifies how individual functions can be constructed. A fam- 
ily of sort functions, for example, might be declared like this: 


template<class T> void sort (vector<T>}); 


A function template specifies an unbounded set of (overloaded) functions. A func- 
tion generated from a function template is called a template function, as is a func- 
tion defined with a type that matches a function template; see §14.5. 

Template arguments are not explicitly specified when calling a function tem- 
plate; instead, overloading resolution is used. For example, 


vector<complex> cv(100); 
vector<int> ci(200); 


void f(vector<complex>& cv, vector<int>é ci) 

{ . 
sort (cv); // invoke sort (vector<complex>) 
sort (ci); // invoke sort (vector<int>) 


} 


A template function may be overloaded either by (other) functions of its name 
or by (other) template functions of that same name. Overloading resolution for 
template functions and other functions of the same name is done in three steps: 

[1] Look for an exact match (§13.2) on functions; if found, call it. 

[2] Look for a function template from which a function that can be called with 

an exact match can be generated; if found, call it. 
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[3] Try ordinary overloading resolution (§13.2) for the functions; if a function is 
found, call it. 
If no match is found the call is an error. In each case, if there is more than one 
alternative in the first step that finds a match, the call is ambiguous and is an error. 
A match on a template (step [2]) implies that a specific template function with 
arguments that exactly matches the types of the arguments will be generated 
(§14.5). Not even trivial conversions (§13.2) will be applied in this case. 


m This can cause the generation of unnecessarily many function definitions. A good 
implementation might take advantage of the similarity of such functions to suppress 
spurious replication. Alternatively, a user can use a few well-chosen template func- 
tion declarations to avoid such generation — after an explicit declaration, trivial 
conversions can be used to find a match (step [1]). 0 


The same process is used for type matching for pointers to functions (§13.3). 
Here is an example: 


template<class T> T max(T a, T b) { return a>b?a:b; }; 


void f(int a, int b, char c, char d) 
{ 
int ml = max(a,b); // max(int a, int b) 
char m2 = max(c,d); // max(char a, char b) 
int m3 = max(a,c); // error: cannot generate 
// max (int, char) 


) 
For example, adding 
int max(int,int); 


to the example above would resolve the third call, by providing a function that 
could be called for max(a,c) after using the standard conversion of char to 
int for c. 

A function template definition is needed to generate specific versions of the 
template; only a function template declaration is needed to generate calls to specific 
versions. 

Every template-arg specified in the template-arg-list must be used in the argu- 
ment types of a function template. 


template<class T> T* create(); // error 


template<class T> 
void f() { // error 
T a; 
Ti) ieee 
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m Should this restriction be a problem it is often possible to achieve a similar effect 
by using a static member function. 


template<class T> class creator [{ 
static T* create(); 
Me 


int* creator<int>::create(); 


o 
All template-args for a function template must be type-arguments. 


m The reason for this is that they must be deduced from actual arguments in calls of 
the template function. O 


14.5c Declarations and Definitions 


There must be exactly one definition for each template of a given name in a pro- 
gram. There can be many declarations. The definition is used to generate specific 
template classes and template functions to match the uses of the template. 

Using a template-class-name constitutes a declaration of a template class. 

Calling a function template or taking its address constitutes a declaration of a 
template function. There is no special syntax for calling or taking the address of a 
template function; the name of a function template is used exactly as is a function 
name. Declaring a function with the same name as a function template with a 
matching type constitutes a declaration of a specific template function. 

If the definition of a specific template function or specific template class is 
needed to perform some operation and if no explicit definition of that specific tem- 
plate function or class is found in the program, a definition is generated. 


m These rules imply that the decision of what functions to generate from function 
template definitions cannot be made until a program is complete, that is, not until it 
is known what function definitions are available. 

As stated, error detection has been postponed to the last possible moment: the 
point after initial linking where definitions are generated for template functions. 
This is too late for many people's tastes. 

As stated, the rules also place the maximum reliance on the programming 
environment. It will be up to the system to find the definitions of the class tem- 
plates, function templates, and classes needed for generating those template function 
definitions. This will be unacceptably complicated for some environments. é 

Both problems can be alleviated by the introduction of mechanisms allowing a 
programmer to say ‘‘*generate these template functions here for these template argu- 
ments.’ This can be made simple enough for any environment and will ensure that 
errors relating to a specific template function definition are detected on request. 

It is not clear, however, whether such mechanisms should be considered part of 
the language or part of the programming environment. It was felt that more experi- 
ence was needed and, for that reason, such mechanisms belonged in the environment 
— at least temporarily. 
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The simplest mechanism for ensuring proper generation of template function 
definitions is to leave the problem to the programmer. The linker will tell which 
definitions are needed, and a file containing noninline template function definitions 
can be compiled together with an indication of which template arguments are to be 
used. More sophisticated systems can be built based on this fully manual base. 0 


The definition of a (nontemplate) function with a type that exactly matches the 


type of a function template declaration is a definition of that specific function tem- 
plate. For example, 


template<class T> void sort(vector<T>& v) { /* ... */ } 


void sort (vector<char*>& v) { /* ... */ ) 


Here, the function definition will be used as the sort function for arguments of type 
vector<char*>. For other vector types the appropriate function definition is 
generated from the template. 


A class can be defined as the definition of a template class. For example, 


template<class T> class stream { /* ... */ ); 


class stream<char> { /* ... */ }; 


Here, the class declaration will be used as the definition of streams of characters 
(stream<char>). Other streams will be handled by template functions generated 
from the function template. 

No operation that requires a defined class can be performed on a template class 
until the class template has been seen. After that, a specific template class is con- 
sidered defined immediately before the first global declaration that names it. 


m In particular, a template class, such as st ream<char>, cannot be defined unless 
its class template has been defined. O 


m Note that the generation of template functions and template classes from templates 
can be done by a well behaved macro expansion process. This ensures that optimal 
Tun-time behavior can be achieved. 

If done naively, such a code replication technique can also lead to excessive 
amounts of generated code. Often, inheritance can be used to achieve code sharing. 
This would involve deriving a template from an ordinary class. For example, 


template<class T> class vector { // general vector type 
T* v; 
int sz; 
public: 
vector(int); 
Té elem(int i) { return vli); } 
Té operator[]) (int i); 
Ph yes 
ye 
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template<class T> 
class pvector : vector<void*> { // build all vector 
// of pointer classes 


// based on vector<void*> 
public: 


pyector (int i) : (i) () 
T*& elem(int i) 

{ return (T*&) vector<void*>::elem(i); } 
T*& operator{)} (int i) 


{ return (T*S) vector<void’>::operator[]} (i); } 
DS Eaa 
Me 


pvector<int*> pivec(100); 
pvector<complex*> icmpvec (200); 
Pvector<char*> pevec (300); 


The implementations of the three vector of pointer classes will be completely shared. 
They are all implemented exclusively through derivation and inline expansion relying 
on the implementation of vector<void*>. The vector<void*> implementa- 
tion is a good candidate for a standard library. 

Another way of using inheritance to achieve code sharing is to derive one tem- 
plate from another. For example, 


template<class T> class B { /* ... */ F: 


template<class T> class D : public B<T> { /* ... */ J; 


14.6c Member Function Templates 


A member function of a template class is implicitly a template function with the 
template arguments of its class as its template arguments. For example, 


template<class T> class vector { 


TX V? 
int sz; 
public: 


vector (int); 
T& operator([] (int); 
T& elem(int i) { return v[i]; } 
i fase 
he 


declares three function templates. The subscript function might be defined like 
this: 


ee es 
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template<class T> T& vector<T>::operator[] (int i) 

{ 
if (i<0 || sz<=i) error("vector: range error"); 
return v[i]; 


@ Note that since the template argument is implicit, applying it to the constructor 
name in a declaration or definition of the constructor is wrong. 


template<class T> class vector { 


PS vias 
vector<T>(int); // error 
vector(int); // ok 


y; 
template<class T> 


vector<T>::vector<T>(int) ( /* ... 7/ ) // error 


template<class T> 
vector<T>::vector(int) { /* ... */ ] // ok 


The template argument for vector<T>::operator[] () will be determined 
by the vector to which the subscripting operation is applied. 


vector<int> v1(20); 
vector<complex> v2 (30); 


v1(3) = 7; // vector<int>::operator[) () 
v2[3) complex (7,8); // vector<complex>::operator[] () 


m It follows that explicit calls of constructors and destructors looks like this: 


void f£(vector<int>* p) 


{ 
ES aries 
Pp->vector<int>::~vector(); 
EERE 
vector<int>& v = vector<int>(10); 
SI asim 


14.7c Friends 


A friend function of a template is not implicitly a template function. For example, 
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template<class T> class task { 
Lier 
friend void next_time(); 
friend task<T>* preempt (task<T>*) ; 
friend task* prmt (task*); // error 
tM le ee 
}; 


Here, next_time() becomes the friend of all task classes, and each task has 
an appropriately typed function called preempt () as a friend. The preempt 
functions might be defined as a template. 


template<class T> 
task<T>* preempt (task<T>* t) { /* ... */ } 


The declaration of prmt () is an error because there is no type task, only 
specific template types, task<int>, task<record>, and so on. 


14.8c Static Members and Variables 


Each template class or function generated from a template has its own copies of 
any static variables or members. For example, 


template<class T> class X { 
static T s; 
By! 

}; 


X<int> aa; 
X<char*> bb; 


Here X<int> has a static member s of type int and X<char*> has a static 
member s of type char*. 
Similarly, 


template<class T> f(T* p) 
{ 

static T s; 

ITERE 
}F 


void g(int a, char* b) 
{ 

f£(&a); 

f (&b); 
} 


Here f (int*) has a static member s of type int and f(char*) has a static 
member s of type char*. 

















Exception Handling 


Exception handling provides a way of transferring control and information to an 
unspecified caller that has expressed willingness to handle exceptions of a given 
type. Exceptions of arbitrary types can be thrown and caught and the set of 
exceptions a function may throw can be specified. The termination model of 
exception handling is provided. Exception handling can be used to support 
notions of error handling and fault-tolerant computing. 


15 Exception Handling (Experimental) 


The exception handling design is experimental; it is a variant of the scheme 
presented in Andrew Koenig and Bjarne Stroustrup: Exception Handling for C+ 
(revised), Proc. USENIX C+ Conference, San Francisco, April 1990. 








Commentary 


The exception handling mechanism is experimental and is therefore described only 
in the commentary. Because in its final form it will belong in the reference 
manual, it is presented in manual style; embedded commentary is used just as in 
the manual proper. 
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15.1c Exception Handling 


Exception handling provides a way of transferring control and information from a 
point in the execution of a program to an exception handler associated with a point 
previously passed by the execution. A handler will be invoked only by a throw- 
expression invoked in code executed in the handler's try-block or in functions 
called from the handler's try-block. 


try-block: 
try compound-statement handler-list 


handler-list: 

handler handler-list,,., 
handler: 

catch ( exception-declaration ) compound-statement 


exception-declaration: 
type-specifier-list declarator 
type-specifier-list abstract-declarator 
type-specifier-list 


throw-expression: 


throw expression. 


A try-block is a statement (§6). A throw-expression is a unary-expression (§5) of 
type void. A throw-expression is sometimes referred to as a ‘‘throw-point.” 
Code that executes a throw-expression is said to ‘‘throw an exception’’; code that 
subsequently gets control is called a ‘‘handler."’ 


m Exception handling is intended to allow code that has encountered a condition it 
cannot cope with to retum to some other code that directly or indirectly invoked it. 
There is no way for an exception handler to request the thread of control to resume 
from the throw-point. In other words, throw implements the termination model of 
exception handling. O 


m Ideally, we would like an exception handling mechanism for C+ to do all the fol- 
lowing: 
[1] provide type-safe transmission of arbitrary amounts of information from a 
throw-point to a handler, 
[2] impose no added cost (in time or space) to code that does not throw an 
exception, 
[3] provide a guarantee that every exception thrown is caught by an appropriate 
handler, 
[4] provide a way of grouping exceptions so that exception handlers can be writ- 
ten to catch groups of exceptions as well as individual ones, 
[5] work correctly by default in a multithreaded program, 
[6] allow cooperation with other languages, especially with C, 
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[7] be easy to understand and use, and 

[8] be easy to implement. 
The mechanism described here provides [1}, [4], (5], and [7]. It can be implemented 
so that it provides [2] and can, if necessary, be extended to provide [3]. Such imple- 
mentations are relatively simple, thus providing [8]. In addition, it is possible to 
provide a portable implementation by generating C code from the C+ source. The 
commentary below (§15.5S) will discuss how [3] clashes with other important aspects 
of programming, making it hard to provide a guarantee against uncaught exceptions 
without punting on ‘‘every’’ or ‘‘appropriate’’ or creating other problems for the 
programmer. O 


@ The design here and the criteria for it evolved slowly. An earlier version of the 
design was presented at the ‘C+ at Work” conference in November 1989 by 
Andrew Koenig and Bjame Stroustrup. The design presented here owes much to the 
discussion generated by that paper and in particular to comments by Toby Bloom, 
Peter Deutch, Ken Friedenbach, Keith Gorlen, Michael O'Riorden, Mike Powell, Jim 
Mitchell, Rob Seliger, Jonathan Shopiro, and Mike Tiemann. The design is clearly 
influenced by the exception handling mechanism in ML. 

Another important source of inspiration was the work on fault-tolerant systems 
done in the University of Newcastle in England under the direction of Brian Randel. 
(m 


@ This design assumes that exceptions are to be used primarily for error handling. 
Altemative uses, such as loop termination and alternate ‘‘normal’* retum paths from 
functions, are clearly possible, but are considered secondary. 

Exception handlers are assumed to be rare compared to function definitions, and 
exceptions are assumed to be thrown infrequently compared to function calls. The 
aim is to allow programs to be constructed out of fault-tolerant subsystems without 
requiring attention to exception handling in every function. In other words, for most 
programs it is not reasonable to make every function fault-tolerant. Rather, some 
functions will be given responsibility for handling all errors occurring both in them- 
selves and in functions called by them. 

Exception handling, as described here, is a language-level concept and not just 
the description of a single implementation; many alternative implementation stra- 
tegies are possible. Nor do the exception handling mechanisms described here dic- 
tate a particular policy for error handling; many alternative strategies for fault 
tolerancy are possible. O 


m The word throw was chosen in preference to the more commonly used signal 
and raise because both signal and raise are functions in the ANSI C standard 
library. Similarly, the word catch was chosen in preference to handle because 
handle is a common identifier in C programs for PC and Mac computers. 0 
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15.2¢ Throwing an Exception 


Throwing an exception transfers control to a handler. An object is passed and the 
type of that object determines which handlers can catch it. For example, 


throw "Help!"; 
can be caught by a handler of some char* type: 


try { 
// 
) 
catch (const char* p) { 
// handle character string exceptions here 


) 
and 


class Overflow { 
// 
public: 
Overflow(char, double, double) ; 
}; 


void f(double x) 
{ 

e rrels 

throw Overflow(‘’+’,x,3.45e107); 
) 


can be caught by a handler 


try { 
[1 rene 
£(1.2); 
the Ne 
} 
catch (Overflow oo) { 
// handle exceptions of type Overflow here 
} 


When an exception is thrown, control is transferred to the nearest handler with 
an appropriate type; ‘‘nearest’’ means the handler whose try-block was most 
recently entered by the thread of control and not yet exited; ‘‘appropriate type™ is 
defined in §15.4. 

A throw-expressiom initializes a temporary object of the static type of the 
operand of throw and uses that temporary to initialize the appropriately-typed 
variable named in the handler. 


m For example, 
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void g() 
{ 
YS al 
Overflow dummy (’?‘',1,2); 
IA. aise 
throw dummy; 
Vi fee 
} 


void f() 
í 
try ( 
gi); 
} 
catch (Overflow oo) { 
FP Viva 
} 
} 


Here the reference oo will refer to a copy of dummy. It cannot refer to the 
automatic storage of function g() from which control is retumed by throw. The 
copy of the expression created by throw, however, will persist until exit from the 
exception handler. O 


Except for the restrictions on type matching mentioned in §15.4 and the use of a 
temporary variable, the operand of throw is treated exactly as a function argument 
in a call (§5.2.2) or the operand of a return statement. 


m Note that the exception parameter does not have to be named. Often a name is 
not needed because the information that an exception of a certain type has been 
thrown is sufficient to handle it. D 


If the use of the temporary object can be eliminated without changing the mean- 
ing of the program except for the execution of constructors and destructors associ- 
ated with the use of the temporary object (§12.1), then the exception in the handler 
may be initialized directly with the argument of the throw expression. 


m Note that defining the transfer of information from a throw-point to a handler as 
initialization makes the transfer type-safe, potentially maximally efficient, and safe 
against race conditions in concurrent systems; it is simply a copy — possibly using a 
copy constructor — of a value of a known type from one location on the stack to 
another. O 


m For exceptions caused by free store storage management, it is not feasible for the 
exception handling mechanism to allocate the temporary object using the ordinary 
free store allocation mechanisms, Further, using the general free store mechanisms 
would be inefficient and would render exception handling vulnerable to errors caused 
by the coruption of free store. Thus, an implementation may decide to keep a pool 
of memory preallocated for the exclusive use of the exception handling mechanism 
and to impose a limit on the amount of memory used for exception handling where 
exceptions related to free store management are involved. O 
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A throw-expression with no operand rethrows the exception being handled. A 
throw-expression with no operand may appear only in a handler or in a function 
directly or indirectly called from a handler. For example, code that must be exe- 
cuted because of an exception yet cannot completely handle the exception can be 
written like this: 

try { 
// 
) 


catch (...) { // catch all exceptions 
// respond (partially) to exception 


throw; // pass the exception to some 
// other handler 


E An alternative and typically more elegant way of ensuring that code is executed 
under all manageable circumstances is to rely on the execution of destructors as 
described in §15.3. O 


m This definition of throw; implies that the exception handling implementation 
needs a concept of a ‘*current exception. It also implies that although an exception 
is considered handled on entry to a handler, the current exception cannot be deallo- 
cated until exit from its handler. O 


15.3c Constructors and Destructors 


As control passes from a throw-point to a handler, destructors are invoked for all 
automatic objects constructed since the try-block was entered. 

An object that is partially constructed will have destructors executed only for its 
fully constructed sub-objects. Also, should a constructor for an element of an 
automatic array throw an exception, only the constructed elements of that array will 
be destroyed. 

The process of calling destructors for automatic objects constructed on the path 
from a try-block to a throw-expression is called ‘‘stack unwinding’. 


m If a debugger is active for a running program and that program throws an excep- 
tion that is not caught, it would be unfortunate if the stack were unwound before 
entry into the debugger. Users are not likely to be pleased with a debugger that does 
such unwinding. O 


mw Destructors can be used to automate management of resources in the presence of 
exceptions. The fundamental idea is to represent the acquisition of a resource as the 
jnitialization of a local variable and then rely on the execution of the destructor to 
release the resource. Consider, for example, a lock in some system. 


be 
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class lock { 
Chicas 
public: 
grab(); 
release(); 
Me 


lock very important; 


To manage acquisition and release we define an auxiliary grab lock class. 


class grab lock { // store and reset class 
locks 1; 
Public: 


grab _lock(lock& 11) :1(11) { l.grab(); ) 


~grab_lock() { 1l.release(); } 
l; 


359 


Then, by allocating a grab lock we ensure the release of the lock by 


grab lock'’s destructor even in the presence of exceptions. 


void my function() 
í 
grab _ lock mine (very important); 


tf esis 


15.4c Handling an Exception 


A handler with type T, const T, T&, or const T& is a match for a throw- 


expression with an object of type E if 
[1] T and E are the same type, or 
[2] T is a public base class of E, or 


[3] T is a pointer type and E is a pointer type that can be converted to T by a 


standard pointer conversion (§4.6). 
For example, 


class Matherr { /* ... */ virtual vf(); }: 
class Overflow: public Matherr { /* ... */ }; 
class Underflow: public Matherr { /* ... */ }; 


class Zerodivide: public Matherr { /* ... */ }; 


void f() 
{ 
try { 
gl); 
} 


(TDA RLS 
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catch (Overflow oo) { 
// 
} 
catch (Matherr mm) { 
// 
} 
} 


Here, the Overflow handler will catch exceptions of type Overflow and the 
Matherr handler will catch exceptions of type Matherr and all types publicly 
derived from Matherr including Underflow and Zerodivide. 


m An alternative style of error handling would be to catch only the base class and 
rely on a virtual function to distinguish between the derived classes. 


void g(); 


void ff() 
{ 
try { 
gl): 
) 
catch (Matherré mm) { 


mm.vf(); // call appropriate vf() 
} 
) 


The exception parameter must be a reference; otherwise only the Matherr part of 
the thrown object would be passed (§12.8). O 


The handlers for a try-block are tried in order of appearance. It is an error to 
place a handler for a base class ahead of a handler for its derived class since that 
would ensure that the handler for the derived class would never be invoked. 


m Examples for which order matters can be constructed with multiple inheritance. 


For example, 
class network_error { /* ... */ }; 
class file_system_error { /* ... */ V; 


class NFerr : 
public network_error, 
public file _system_error { /* ... */ N; 


void f() 
{ 
try { 
RE Ne 
} 


Section 15.4¢ Handling an Exception 361 





catch (network _erroré ne) { 
VE se 
) 
catch (file_system_errors fse) { 
if aes ig 
} 
} 


Here, the order of handlers is significant when catching an NFerror. O 


A ... in a handler’s exception-declaration functions similarly to ... in a 
function argument declaration; it specifies a match for any exception. If present, a 
handler must be the last handler for its try-block. 
If no match is found among the handlers for a try-block, the search for a match- 
ing handler continues in a dynamically surrounding try-block. 


m Thus, not specifying a ... handler for a try block is equivalent to specifying 
catch (...) { throw; } 


o 


If no matching handler is found in a program, the function terminate () (§15.7) 
is called. 

An exception is considered handled upon entry to a handler. The stack will 
have been unwound at that point. 


m For example, 


struct Foo { 

char* p; 

Foo(char* pl): p(pl) { ) 
1 


void toss() 
( 
char buffer[10); 
strcpy (buffer, "Foo!"); 
throw Foo (buffer); // bad idea! 
// pointer to local in exception 
) 


Here the buffer in f() will most likely be corrupted by the stack unwinding 
before a handler gets a chance to look at it. O 


15.5c Exception Specifications 


Raising or catching an exception affects the way a function relates to other func- 
tions. It is possible to list the set of exceptions that a function may directly or 
indirectly throw as part of a function declaration. An exception-specification can 
be used as a suffix of a function declarator. 
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exception-specification: 
throw ( Npe-list.,, ) 


type-list: 
type-name 
type-list , type-name 


For example, 


void f() throw (X,Y) 
{ 

// 
} 


m Murphy's Law for exception handling reads ‘Any exception that can be thrown 
will be thrown,’ so this function declaration should be read as “f () will throw X 
and Y". O 


An attempt by a function to throw an exception not in its exception list will 
cause a call of the function unexpected (); see §15.8. 


@ A simple way to enforce this rule would be to generate code like this for f (): 


void f() 
{ 
try { 
hie PTE 
} 
catch (X) { throw; } 
catch (Y) { throw; } 
catch (...) { unexpected(); ) 


o 


m The default effect of unexpected () is to call terminate (); the default 
effect of terminate () is abort () (§15.7). That is, a violation of the guarantee 
expressed by an exception-specification is by default considered a serious design 
error. The programmer defining f() can ensure that this never happens by brute 
force. For example, 


void f£() throw(x,Y) 


{ 
try { 
Udo 
} 
catch (X) { throw; ) 
catch (Y) { throw; } 
catch (...) { throw X(); } 
j f 


More subtle approaches, however, such as a proof that only X and Y (or classes 
derived from X and Y) can be thrown by f() and code called from f (), are 
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sometimes possible. O 


An implementation may not reject an expression simply because it may throw 
an exception not specified in an exception-specification of the function containing 
the expression; the handling of violations of an exception-specification is done at 
run-time. 


@ For example, 


extern "C" £(); // we have no way of guessing 
// which exceptions f() might throw 


void g() throw(X); // g() will throw X 


void h() throw() // h() may not throw any exceptions 
{ 

f(); // legal, but suspect 

gl); // legal, but highly suspect 
} 


This program must be accepted by a compiler and any errors caused by f () throw- 
ing an exception must be caught at run-time. Static analyzers can be provided to 
help programmers avoid such run-time errors, however. Compilers can also help by 
warming about suspect constructs such as the call of g() above. O 


A function with no exception-specification may throw any exception. 

A function with an empty exception-specification, throw(), may not throw 
any exception. 

A function that may throw an exception of a class X may throw an exception of 
any class publicly derived from X. 

An exception-specification is not considered part of a function’s type. 


m Ideally, only exceptions mentioned in an exception-specification will be thrown. 
Why dont we make exception-specifications part of a function's type and perform a 
complete static type check? Why don’t we enforce the ideal by requiring every 
function to have an exception-specification and reject every program where an unex- 
pected exception occurs? 

Preventing such errors at compile-time would be a great bother to the program- 
mer and the checking would consequently be subverted. Such subversion could take 
may forms. For example, calls through C functions could be used to render the 
static checking meaningless, programmers could declare functions to throw all excep- 
tions by default, or tools could be written to create exception-specifications automati- 
cally, listing all possible exceptions. The effect would be to eliminate the bother as 
well as the safety checks that were designed into the mechanism. 

Further, if a function were changed to throw a new exception, all functions that 
directly or indirectly call it would have to be changed and recompiled. This would 
be a nuisance and could lead to significant delays since libranes would have to agree 
on a set of exceptions used to work together as part of a single program. For exam- 
ple, if subsystem X handles exceptions from subsystem Y and the supplier of Y 
introduces a new kind of exception, then X’s code will have to be modified to cope. 
A user of X and Y will not be able to upgrade to a new version of Y until X has 
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been modified. Where many subsystems are used this could cause cascading delays. 

In other words, it is infeasible to recompile all code in a system simply because 
a subsystem has been modified to possibly throw a new exception. This implies that 
it should be possible to replace a function with another that differs only in its 
exception-specification without requiring recompilation of its callers. 

Naturally, in a restricted environment one might impose stricter rules based on 
Separate static analysis or compiler wamings, but for general use the flexibility 
seems essential. O 


15.6c Special Functions 


The exception handling mechanism relies on two functions, terminate() and 
unexpected (), for coping with errors related to the exception handling mechan- 
ism itself. 


m Note that these functions must be specific to individual threads in a multi-threaded 
program. However, exactly how that is achieved is not supposed to be visible to a 
user. A programmer need not know if a program is multithreaded to use exceptions 
correctly. O 


15.6.lc The terminate() Function 


Occasionally, exception handling must be abandoned for less subtle error handling 
techniques. For example, 
— when the exception handling mechanism cannot find a handler for a thrown 
exception, 
— when the exception handling mechanism finds the stack corrupted, or 
— when a destructor called during stack unwinding caused by an exception 
tries to exit using an exception. 
In such cases, 


void terminate(); 


is called; terminate() calls the last function given as an argument to 
set_terminate (): 


typedef void(*PFV) (); 
PFV set_terminate(PFV); 


The previous function given to set_terminate() will be the return value; this 
enables users to implement a stack strategy for using terminate (). The default 
function called by terminate () is abort (). 

Selecting a terminate function that does not in fact terminate but tries to retum 
to its caller is an error. 


m Note that terminate() may enforce this rule by calling abort () should a 
user-supplied function retum. The use of terminate () is reserved for problems 
beyond the scope of ordinary exception handling. An example of a reasonable 
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terminate () that does not abort () is a function that discards all data within its 
address space as probably corrupted and re-initializes the process. O 


15.6.2c The unexpected () Function 


If a function with an exception-specification throws an exception that is not listed 
in the exception-specification, the function 


void unexpected (); 


is called; unexpected() calls the last function given as an argument to 
set_unexpected (): 


typedef void(*PFV) (); 
PFV set_unexpected (PFV) ; 


The previous function given to set_unexpected() will be the return value; this 
enables users to implement a stack strategy for using unexpected(). The 
default function called by unexpected() is terminate(). Since the default 
function called by terminate() is abort (), this leads to immediate and pre- 
cise detection of the error. 


m The idea is that a violation of a promise to throw only a specified set of excep- 
tions is a serious design error that must be fixed before any further progress can be 
made. 

There are, however, cases where having a subsystem unconditionally terminate is 
unacceptable. Some such cases can be handled by having terminate/() re- 
initialize the offending process, but in other cases this approach is too Draconian or 
infeasible because of lack of hardware support. The caller of a function with an 
exception-specification can use set_unexpected() to reset the penalty for 
throwing an unexpected exception by the called function to something more suitable 
for the caller. For example, 


extern void f() throw(X,Y); 


void pass through() { throw; } 


void g() 
{ 
PFV old = set_unexpected(Spass_through); 
try { 
£(); 
} 
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} 


catch (X) [{ 
rý 
} 
catch (Y) { 
VALI 
) 
catch (...) { 
// something strange happened in f() 
// recover! 
} 
set_unexpected (old); 


Here, if £() throws an exception that is not X or Y, unexpected() will call 
Pass_ through (), which in tum will rethrow the exception for g() to catch. 

The example above was deliberately naively written. Clearly much care will 
have to be taken to reset unexpected () on all retums from g(). A better style 
can be achieved using the ‘‘resource acquisition is initialization’’ approach described 


in §15.2: 


extern void f() throw(X,Y); 


void pass _through() { throw; } 


class SUE { // store and reset class 


PFV old; 


public: 


J; 


SUE (PFV f) { old = set_unexpected(f); } 
~SUE() { set_unexpected(old); } 


void g() 


{ 


SUE mine (&pass through); // set_unexpected to 
// pass_through and 
// guarantee reset 
try í 
f(); 
) 
catch (X) { 
Va pres 
} 
catch (Y) { 
Th vsie 
} 
catcha(se.) of 
// something strange happened in f() 
// recover! 
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@ It has been suggested that the proper response to an attempt to throw an unex- 
pected exception through an interface would be to throw a special exception 
UNEXPECTED. This can be easily handled using set_unexpected (): 


class UNEXPECTED ( /* ... */ } ; 

void throw_UNEXPECTED() { throw UNEXPECTED; } 
ST ta 

set_unexpected(éthrow UNEXPECTED); 


However, many users with experience with exception handling mechanisms where 
the default style is to raise a distinguished exception prefer termination. O 




















Preprocessing 


This chapter describes preprocessing in C++. C+ preprocessing, which is based 
on ANSI C preprocessing, provides macro substitution, conditional compilation, 
and source file inclusion. In addition, directives are provided to control line 
numbering in diagnostics and for symbolic debugging, to generate a diagnostic 
message with a given token sequence, and to perform implementation-dependent 
actions (the #pragma directive). Certain predefined names are available. These 
facilities are conceptually handled by a preprocessor, which may or may not 
actually be implemented as a separate process. 


16 Preprocessing 


A CH implementation contains a preprocessor capable of macro substitution, condi- 
tional compilation, and inclusion of named files. 

Lines beginning with #, optionally preceded by space and horizontal tab charac- 
ters, (also called *‘directives*') communicate with this preprocessor. White space 
may appear before the #. These lines have syntax independent of the rest of the 
language; they may appear anywhere and have effects that last (independent of the 
scoping rules of C+) until the end of the translation unit (§2). 

A preprocessing directive (or any other line) may be continued on the next line 
in a source file by placing a backslash character, \, immediately before the new- 
line at the end of the line to be continued. The preprocessor effects the continua- 
tion by deleting the backslash and the new-line before the input sequence is divided 
into tokens. A backslash character may not be the last character in a source file. 

A preprocessing token is a language token (§2.1), a file name as in a 
#include directive, or any single character, other than white space, that does not 
match another preprocessing token. 
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m Except for the treatment of CH // comments and C+ tokens that are not also C 
tokens (. *, ->*, and : ;), CH preprocessing is ANSI C preprocessing. 

Because an ANSI C style preprocessor may not be available for all CH imple- 
mentations, the commentary (§16.3) describes Classic C preprocessing. O 


16.1 Phases of Preprocessing 


Preprocessing is defined to occur in several phases. An implementation may col- 
lapse these phases, but the effect must be as though they had been executed. 


If needed, new-line characters are introduced to replace system-dependent end- 
of-line indicators and any other necessary system-dependent character set trans- 
lations are done. Trigraph sequences are replaced by their single character 
equivalents (§16.2). 


Each pair of a backslash character \ immediately followed by a new-line is 
deleted, with the effect that the next source line is appended to the line that 
contained the sequence. 

The source text is decomposed into preprocessing tokens and sequences of 
white space. A single white space replaces each comment. A source file may 
not end with a partial token or comment. 


m Unless a C preprocessor has been adapted for use with C+, it will not recognize 
// comments. Thus, macro replacement will inappropriately be done for macro 
names appearing within // comments, and // comments within macro definitions 
will not be correctly translated to white space. 

Similarly, an unmodified C preprocessor will not recognize .*, ->*, and :: as 
single tokens. 0 


Preprocessing directives are executed and macros are expanded (§16.3, §16.4, 
§16.5, §16.6, §16.7, and §16.8). 


Escape sequences in character constants and string literals are replaced by their 
equivalents (§2.5.2). 


m The value of a character constant within a preprocessing directive may or may not 
have the same numeric value as it has within any other expression. O 


Adjacent string literals are concatenated. 


The result of preprocessing is syntactically and semantically analyzed and 
translated, then linked together as necessary with other programs and libraries. 
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16.2 Trigraph Sequences 


Before any other processing takes place, each occurrence of one of the following 
sequences of three characters (‘‘trigraph sequences) is replaced by the single 
character indicated in the table below. 


??= e $ Calan | 
Hf oN STINA 


Rá . 223 | 


For example, 


becomes 


#define arraycheck(a,b) a[b] || bla] 


m ANSI C introduced the notion of trigraphs to allow implementation of C on sys- 
tems that do not support the full ASCII character set. In particular, the trigraph 
definitions allow a mapping from the ISO 646-1983 Invariant Code Set character set 
to ASCII. 

Unfortunately, this doesn’t address the problem of writing C and C+ programs 
on terminals where the all the character positions reserved for alphabetic characters 
are assigned to letters. The reason is that the ASCII (ANSI3.4-1968) special charac- 
ters [, J, {, }, l, and \ occupy character positions that in most European national 
ISO 646 character sets are occupied by leners not found in the English alphabet. 
For example, the Danish representations of these character values are £. A, 2, å, a 
and Ø. No significant amount of text can be written in Danish without them. This 
leaves Danish programmers with the unpleasant choice of acquiring computers sys- 
tems that handle full 8 bit character sets, such as ISO 8859/1/2, not using three 
vowels of their native language, or not using C+. Speakers of French, German, 
Spanish, Italian, and so on, face the same dilemma. We speculate that this has been 
a notable barrier to the use of C in Europe, especially in commercial settings where 
the use of 7 bit national character sets is pervasive in many countries. 

For example, consider this innocent-looking ANSI C and C+ program: 


int main(int argc, char* argv[}) 

í 
if (argce<l |I *argv[1]=="'\0’) return 0; 
printf("Hello, is\n",argv[1]); 

} 


On a standard Danish terminal or printer this program will appear like this: 


int mainfint argc, char* argvE A) 
æ 
if (arge<l ao *argv£ 1A=='90") return 0; 
r printf("Hello, ts@n",argv£ 1A); 
å 


It is amazing to realize that some people can actually read and write this with ease, 
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The trigraph version is little better. 
int main(int argc, char* arg??(??)) 
?2?< 
if (argc<1 ??!??! *argv??(1??)=='2?/0') return 0; 
printf("Hello, &s??/n",argv??(1??)); 
??> 
For a further discussion of these issues, see Keld Simonsen and Bjame Stroustrup: A 
European Representation for ISO C in the Vol. 9 No. 2 Summer 1989 issue of the 
European UNIX® Systems Users Group Newsletter. A partial solution would be to 
augment the trigraphs, which are necessary to allow character constants and string 
values, with keywords and new character combinations, as is often done for national 
dialects of languages such as Pascal. A comprehensive solution is possible only 
through a pervasive upgrading of complete computer systems to allow national char- 
acters to coexist with special characters such as \ and f in all software. O 


16.3 Macro Definition and Expansion 
A preprocessing directive of the form 
#define identifier token-string 


causes the preprocessor to replace subsequent instances of the identifier with the 
given sequence of tokens. White space surrounding the replacement token 
sequence is discarded. Given, for example, 


#define SIDE 8 
the declaration 

char chessboard[SIDE) [SIDE]; 
after macro expansion becomes 

char chessboard[8] [8]; 


An identifier defined in this form may be redefined only by another #define 
directive of this form provided the replacement list of the second definition is 
identical to that of the first. All white space separations are considered identical. 

A line of the form 


#define identifier( identifier , ... , identifier ) token-string 


where there is no space between the first identifier and the ( is a macro definition 
with parameters, or a ‘‘function-like’’ macro definition. An identifier defined as a 
function-like macro may be redefined by another function-like macro definition pro- 
vided the second definition has the same number and spelling of parameters and the 
two replacement lists are identical. White space separations are considered identi- 
cal. 

Subsequent appearances of an identifier defined as a function-like macro fol- 
lowed by a (, a sequence of tokens delimited by commas, and a ) are replaced by 
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the token string in the definition. White space surrounding the replacement token 
sequence is discarded. Each occurrence of an identifier mentioned in the parameter 
list of the definition is replaced by the token representing the corresponding actual 
argument in the call. The actual arguments are token strings separated by commas; 
commas in quoted strings, in character constants, or within nested parentheses do 
not separate arguments. The number of arguments in a macro invocation must be 
the same as the number of parameters in the macro definition. 

Once the arguments to a function-like macro have been identified, argument 
substitution occurs. Unless it is preceded by a # token (§16.3.1) or is adjacent to a 
## token (§16.3.2), a parameter in the replacement list is replaced by the 
corresponding argument after any macros in the argument have been expanded 
(§16.3.3). 

For example, given the macro definitions 


#define index_mask OXFFOO 

#define extract (word, mask) word & mask 
the call 

index = extract (packed_data, index_mask) ; 
expands to 


index = packed data & OXFFOO; 


m Semicolons in, or at the end of, a token-string are part of that sequence. Thus 


define MAX 256; 
int upperbound=MAX~1; 


expands to the two statements 
int upperbound=256;-1; 
which is probably not what the user intended. O 


In both forms the replacement string is rescanned for more defined identifiers 
(§ 16.3.3). 


16.3.1 The # Operator 


If an occurrence of a parameter in a replacement token sequence is immediately 
preceded by a # token, the parameter and the # operator will be replaced in the 
expansion by a string literal containing the spelling of the corresponding argument. 
A \ character is inserted in the string literal before each occurrence of a \ ora " 
within or delimiting a character constant or string literal in the argument. 

For example, given 


#define path(logid,cmd) "/usr/" logid "/bin/" #cmd 
#define joe joseph 


the call 
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char* mytool=path (joe, readmail) ; 
yields 
char* mytool="/usr/" "joe" "/bin/" "“readmail"; 
which is later concatenated (§16.1) to become 
char* mytool="/usr/joe/bin/readmail"; 
m Note that the argument to the € operator is not available for further macro replace- 
ment so the result is not 


char* mytool="/usr/joseph/bin/readmail"; 


16.3.2 The ## Operator 


If a ## operator appears in a replacement token sequence between two tokens, first 
if either of the adjacent tokens is a parameter it is replaced, then the ## operator 
and any white space surrounding it are deleted. The effect of the ## operator, 
therefore, is concatenation. 

Given 


#define inherit (basenum) public Pubbase ## basenum, \ 
private Privbase ## basenum 


the call 
class D : inherit(1l) { ); 
yields 
class D : public Pubbasel, private Privbasel ( ); 


Any macros in the replaced tokens adjacent to the ## are not available for 
further expansion, but the result of the concatenation is. Given 


#define concat (a) a ## ball 
#define base ; B 
#define baseball sport 
the call 
concat (base) 
yields 
sport 
and not 


Bball 
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16.3.3 Rescanning and Further Replacement 


After all parameters in the replacement list have been replaced, the resulting list is 
rescanned for more macros to replace. If the name of the macro being replaced is 
found during this scan or during subsequent rescanning, it is not replaced. 

A completely replaced macro expansion is not interpreted as a preprocessing 
directive, even if it appears to be one. 


16.3.4 Scope of Macro Names and f#undef 


Once defined, a preprocessor identifier remains defined and in scope (independent 
of the scoping rules of C+) until the end of the translation unit or until it is unde- 
fined in a #undef directive. 

A #undef directive has the form 


#undef identifier 


and causes the identifier’s preprocessor definition to be forgotten. If the specified 
identifier is not currently defined as a macro name, the #undef is ignored. 


16.4 File Inclusion 


A control line of the form 
#include <filename> 
causes the replacement of that line by the entire contents of the file filename. The 


named file is searched for in an implementation-dependent sequence of places. 
Similarly, a control line of the form 


include "filename" 


causes the replacement of that line by the contents of the file filename, which is 
searched for first in an implementation-dependent manner. If this search fails, the 
file is searched for as if the directive had been of the form 


#include <filename> 


m The intention of defining the two syntaxes for #include lines as above is that 
an implementation provide as closely as possible the functionality of Classic C, in 
which 


finclude <ilename> 


meant that the file was to be searched for in a defined sequence of standard places, 
and 


#finclude "filename" 


meant that the file was to be searched for first in the directory of the original source 
file and then in the sequence of standard places. It cannot be assumed, however, 
that the notion of ‘directory’ will make sense for all implementations of C++. The 
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semantics of #include, therefore, are highly implementation dependent. An 
implementation should specify the places that will be searched for a file to be 
included. O 


Neither the new-line character nor > may appear in filename delimited by < and 
>. If any of the characters ’, \, or ", or either of the sequences /* or // appear 
in such a filename the behavior is undefined. 

Neither the new-line character nor " may appear in a filename delimited by a " 
pair, although > may appear. If either of the characters ‘ or \ or either of the 
sequences /* or // appear in such a filename the behavior is undefined. 


m How a sequence of preprocessing tokens between a < and > preprocessing token 
pair or a pair of "'s will be combined into a single file name preprocessing token 
will depend on the implementation. Treatment of white space within the delimiters 
will vary. Typically, a sequence of white space that is the result of a macro expan- 
sion will be treated as a single space character, while other sequences of white space 
will be preserved. 

Some implementations will ignore case distinctions in file names. Further, the 
number of significant characters in a file name may be limited by an implementation. 
To provide functionality consistent with ANSI C, however, an implementation must 
provide at least six significant characters. O 


If a directive appears of the form 
#include foken-string 


not matching either of the forms given above, the preprocessing tokens within 
token-string will be processed as normal text. The resulting directive must match 
one of the forms defined above and will be treated as such. 

A #include directive may appear within a file that is being processed as a 
tesult of another #include directive. 

An implementation may impose a limit on the depth of nesting of #include 
directives within source files that have been read while processing a #include 
directive in another source file. 


m Usually such a limit will be attributable to the host operating system's limit on the 
number of open files. O 


16.5 Conditional Compilation 


The preprocessor allows conditional compilation of source code. The syntax for 
conditional compilation follows: 


conditional: 


if-part elif-parts,,,, else-part,,, endif-line 


om 


if-part: 
if-line text 
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if-line: 

# if constant-expression 

# ifdef identifier 

# ifndef identifier 
elif-parts: 

elif-line text 

elif-parts elif-line text 
elif-line: 

# elif constant-expression 
else-part: 

else-line text 
else-line: 

# else 
endif-line: 

# endif 


The constant expression in the #if£ and #elif’s (if any) are evaluated in the 
order in which they appear until one of the expressions evaluates to a nonzero 
value. C+ statements following a line with a zero value are not compiled, nor do 
preprocessor directives following such a line have any effect. When a directive 
with a nonzero value is found, the succeeding #elif’s, and #else’s, together 
with their associated text (CH statements and preprocessor directives) are ignored. 
The text associated with the successful directive (the first whose constant expres- 
sion is nonzero) is preprocessed and compiled normally. If the expressions associ- 
ated with the #if and all #elif’s evaluate to zero, then the text associated with 
the #else (if any) is treated normally. 

Within the constant-expression in a #if or #e1if, a unary operator defined 
can be used in either of the forms 


defined identifier 


or 
defined (identifier) 


When applied to an identifier, its value is 1 if that identifier has been defined with 
a #define directive and not later undefined using #undef; otherwise its value is 
0. The identifier defined itself may not be undefined or redefined. 

After any defined operators are evaluated, any remaining preprocessor mac- 
ros appearing in the constant expression will be replaced as described in §16.3. 
The resulting expression must be an integral constant expression as defined in 
§5.19, except that types int and unsigned int are treated as long and 
unsigned long respectively, and it may not contain a cast, a sizeof operator, 
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or an enumeration constant. 
A control line of the form 


#ifdef identifier 
is equivalent to 

#if defined identifier 
A line of the form 

#ifndef identifier 
is equivalent to 

#if !defined identifier 


Conditional compilation constructs may be nested. An implementation may 
impose a limit on the depth of nesting of conditional compilation constructs. 


16.6 Line Control 
For the benefit of programs that generate CH code, a line of the form 
#line constant "filename "op 


sets the predefined macro __LINE___ (§16.10), for purposes of error diagnostics 
or symbolic debugging, such that the line number of the next source line is con- 
sidered to be the given constant, which must be a decimal integer. If "filename" 
appears, _ FILE _ (§16.10), is set to the file named. If "filename" is absent 
the remembered file name does not change. 

Macros appearing on the line are replaced before the line is processed. 


16.7 Error Directive 
A line of the form 
#error token-string 


causes the implementation to generate a diagnostic message that includes the given 
token sequence. 


16.8 Pragmas 
A line of the form 
#pragma foken-string 


causes an implementation-dependent behavior when the token sequence is of a form 
recognized by the implementation. An unrecognized pragma will be ignored. 
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16.9 Null Directive 


The null preprocessor directive, which has the form 
# 


has no effect. 


16.10 Predefined Names 


Certain information is available during compilation through predefined macros. 


__LINE__ A decimal constant containing the current line number in the C++ 
source file. 


__FILE___A string literal containing the name of the source file being compiled. 


__DATE__ A string literal containing the date of the translation, in the form 
"Mmm dd yyyy", or "Mmm d yyyy" if the value of the date is less than 
10. 


__TIME __ A string literal containing the time of the translation, in the form 
"hh:mm:ss". 


In addition, the name __cplusplus is defined when compiling a C+ pro- 
gram. 

These names may not be undefined or redefined. 
LINE__ and __FILE__ can be set by the #line directive (§16.6). 


Whether _ STDC__ is defined and, if so, what its value is are implementation 
dependent. 


m Some C+ implementations share a preprocessor, modified to handle // comments 
and C+ operators, with C. A C compiler that conforms to the ANSI C standard will 
define _ STDC__ with the value 2 and will disallow applying a #define or 
#undef operator to ___STDC__. 

C} implementations that share header files with C may need to define 
STDC a 


m Implementations are free to predefine additional macro names, which may be rede- 
fined through the #define directive or undefined through the #undef directive or 
a command line option. O 
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Commentary 


16.1c CH Constructs versus #define 


The functionality of the CH constructs const and inline can often be used 
where a C program would use a #define. The traditional C construct 


#define MAXCHARS 80 
can be replaced by the C+ declaration 
const int MAXCHARS=80; 


and the identifier MAXCHARS can be used within the program in the same way. 
The C+ construct has the advantage, however, that the symbol MAXCHARS can be 
made available to a symbolic debugger, while preprocessing symbols are generally 
not. 

A macro such as 


#define max (x,y) CORI SY seam 69 ee y) 
can be replaced for integers by the C+ inline function 


inline int max(int x, int y) 
{ 
return (x >y?x : Y); 


) 


with no loss of efficiency. Templates ($14) can be used when a similar function 
will be needed for multiple types. The name of an inline or template function can 
be passed to a symbolic debugger. Further, the potential for error when a macro is 
invoked with an expression that has side effects, as in the following, for example, 


max (f(x), z++); 


is eliminated when an inline or template function is used. 


16.2c Compatibility 


Differences between the ANSI C style preprocessing described above and older 
preprocessors are discussed in the following sections. 


16.2.1c Tokenization Versus Characterization 


The phases of translation specified by the ANSI C Standard, on which the defini- 
tion of preprocessing for CH is based, are ‘‘token-based;’’ the ‘‘Reiser’’ model, on 
which many existing preprocessors are built, is ‘‘character-based.’’ Although it 
would be difficult to list all cases where the meaning of a program is affected by 
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this change, two examples follow. 
Given 
#define MINUS - 
i=MINUS-j; 
a Reiser preprocessor will produce i=--j;, with the effect that i is assigned the 


result of applying the prefix decrement operator to the value of j. The output of 
an ANSI C conforming preprocessor will be in effect 


i=--j; 
Thus i will be assigned the result applying the minus operator to the result of 
applying the minus operator to the value of j. 

Given 


#define replace() NEW 
#define NEWSTR getstr(Str) 


replace ()STR 


a Reiser preprocessor yields getstr (Str), while an ANSI C conforming prepro- 
cessor will produce in effect NEW STR. 

Providing both token-based and character-based preprocessing may be unduly 
expensive, both in the complexity of implementation and in performance penalties. 
Furthermore, the affected code would have been inherently ambiguous, having 
relied on undefined and undocumented behavior. One would hope that little such 
code exists. An implementation may elect to provide a Reiser preprocessor for 
users who have existing programs that depend on “‘Reiser’’ behavior. Neverthe- 
less, such users would be well advised to convert their programs to rely on well- 
defined constructs. 


16.2.2c Tokenless Arguments 


The ANSI C Standard says the behavior is undefined given an argument that con- 
tains no tokens, but many C and C+ implementations have treated a tokenless 
argument as a null token. That is, 


#define SUB(x,y) (x-y) 
SUB (, 2) 


would be translated to (-2). For compatibility, some implementations will con- 
tinue to treat a tokenless argument as though a null argument were provided. 


16.2.3c Rescanning and Further Replacement 


The ANSI C Standard specifies that if the name of a macro being replaced is found 
during the scanning of the replacement list (or any subsequent rescanning), this 
occurrence of the macro name is not to be replaced. This may be interpreted to 
differ from Classic C, which says that a replacement string is to be rescanned for 
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more defined identifiers. The following code fragment, for example, 


#define m(a) a(w) 
#define w 0,1 
m(m) 


will yield 0,1 (0,1) when compiled by some older preprocessors, but must yield 
m(0, 1) in an ANSI C conforming implementation. 


16.2.4c Stringizing 


Although not defined in Classic C, many existing preprocessors provide the func- 
tionality of the ANSI C # operator, sometimes called ‘‘stringizing."’ If, in the 
replacement list of a function-like macro definition, there is a string literal token, 
the string contents are examined for the spelling of the formal arguments. If any 
formal arguments are found, their characters are replaced with the spelling of the 
actual arguments. For example, given 


#define stringize(a) "a" 
stringize (hello world) 


such a preprocessor yields "hello world”. An ANSI C conforming preproces- 
sor, however, must yield "a". 


16.2.5c Charizing 


” 


Some old preprocessors also provide a functionality, called ‘‘charizing,’* that is not 
equivalent to any ANSI C operator, nor is it defined in Classic C. If, in the 
replacement list of a function-like macro definition, there is a character constant 
token, the character constant contents are examined for the spelling of the formal 
arguments. If any formal arguments are found, their characters are replaced with 
the spelling of the actual arguments. Given, for example, 


#define charize(a) ‘a’ 
charize (q) 


such a preprocessor yields ’q’, while an ANSI C conforming preprocessor must 
yield a’. 
16.2.6c Concatenation 


Some old preprocessors provide the functionality of ANSI C’s ## operator, not 
defined in Classic C, by concatenating a macro parameter and an identifier, an 
integral constant, or another macro parameter separated only by a comment in the 
replacement list. Given, for example, 


#define paste (a,b) a/* */b 
paste (con, catenate) 


such a preprocessor yields concatenate, while an ANSI C conforming 
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preprocessor must yield con catenate. 


16.2.7c Trailing Tokens - #else and fendif 


Although Classic C never defined the behavior when tokens follow an felse or 
#endif directive (‘‘trailing tokens’’) and the ANSI C Standard disallows them, 
some implementations have accepted code that contains them. Many programmers 
use a programming style in which text following the #else and #endif identi- 
fies the matching #if, #ifdef, or #ifndef directive. For compatibility, some 
implementations may choose to ignore trailing tokens. - 


16.3c Classic C Preprocessing 


Because many CH implementations will be used where an ANSI C style preproces- 
sor is not available, this description of Classic C preprocessing is presented. 

Like the ANSI C-based preprocessor described above, a Classic C preprocessor 
is capable of macro substitution, conditional compilation, and inclusion of named 
files. Classic C did not define trigraph sequences, the #, ## and defined opera- 
tors, the #elif directive, error directives, pragmas, null directives, or the 
__LINE__, __FILE__, __DATE__, and __ TIME — macros. The name 
__ cplusplus, however, is defined even when preprocessing a CH program with 
a Classic C preprocessor. 

As with ANSI C style preprocessing, lines beginning with # are preprocessor 
directives. These lines have syntax independent of the rest of the language; they 
may appear anywhere and have effects that last (independent of scope) until the end 
of the translation unit. 

For the remainder of this section, “‘preprocessor’’ refers to a Classic C prepro- 
cessor. 


16.3.1¢ Classic C Token Replacement 
A compiler control line of the form 
#define identifier token-string 


causes the preprocessor to replace subsequent instances of the identifier with the 
given string of tokens. Semicolons in, or at the end of, the token string are part of 
that string. 

A line of the form 


#define identifier ( identifier , ... , identifier ) token-string 


where there is no space between the first identifier and the (, is a macro definition 
with arguments. Subsequent instances of the first identifier followed by a (, a 
sequence of tokens delimited by commas, and a ) are replaced by the token string 
in the definition. Each occurrence of an identifier mentioned in the formal argu- 
ment list of the definition is replaced by the corresponding token string from the 
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call. The actual arguments in the call are token strings separated by commas; how- 
ever Commas in quoted strings or protected by parentheses do not separate argu- 
ments. The number of formal and actual arguments must be the same. Strings and 
character constants in the token string are scanned for formal arguments, but strings 
and character constants in the rest of the program are not scanned for defined iden- 
tifiers. 


m Unless a Classic C preprocessor has been adapted for use with CH, it will not 
recognize // comments. Thus, macro replacement will inappropriately be done for 
macro names appearing within // comments, and // comments within macro defin- 
itions will not be correctly translated to white space. O 


In both forms the replacement string is rescanned for more defined identifiers. 
In both forms a long control line may be continued on another line by writing \ at 
the end of the line to be continued. 

A control line of the form 


fundef identifier 


causes the identifier’s preprocessor definition to be forgotten. 


16.3.2c Classic C File Inclusion 


A compiler control line of the form 
#include "filename" 


causes the replacement of that line by the entire contents of the file filename. The 
named file is searched for first in the directory of the original source file, and then 
in a sequence of specified or standard places. Alternatively, a control line of the 
form 


#include <filename> 


searches only the specified or standard places, and not the directory of the source 
file. (How the places are specified is not part of the language.) 


m Because file systems vary on different operating systems and different machines, 
there are several implementation dependencies that affect source file inclusion. An 
implementation should specify the places that will be searched for a file, as well as 
how the file is to be identified. 

Some implementations will ignore case distinctions in file names. Further, the 
number of significant characters in a file name may be limited by an implementation. 

How a sequence of preprocessing tokens between a < and > preprocessing token 
pair Or a pair of "s will be combined into a single header name preprocessing 
token will also depend on the implementation. Implementations may differ in their 
treatment of white space within the delimiters. Typically, a sequence of white space 
that is the result of a macro expansion will be treated as a single space character, 
while other sequences of white space will be preserved, O 


#include’s may be nested. 
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Some implementations will impose a limit on the depth of nesting of 
#include directives within source files that have been read while processing a 
#include directive in another source file. 


E Usually such a limit will be attributable to a limit in the host operating system on 
the number of files that may be open. O 


16.3.3¢ Classic C Conditional Compilation 
A compiler control line of the form 
#if expression 


checks whether the expression evaluates to nonzero. The expression must be a 
constant expression (§5.19). A control line of the form 


#ifdef identifier 


checks whether the identifier is currently defined in the preprocessor, that is, 
whether it has been the subject of a #define control line. A control line of the 
form 


#ifndef identifier 
checks whether the identifier is currently undefined in the preprocessor. 


All three forms are followed by an arbitrary number of lines, possibly contain- 
ing a control line 


else 


and then by a control line 
#endif 


If the checked condition is true then any lines between #else and fendif are 
ignored. If the checked condition is false then any lines between the test and a 
#else or, lackinga #else, the #endif, are ignored. 

These constructions may be nested. An implementation may impose a limit on 
the depth of nesting of conditional compilation constructs. 


16.3.4c Classic C Line Control 
For the benefit of other preprocessors that generate CH programs, a line of the 
form 

#line constant "filename "y 
causes the compiler to believe, for purposes of error diagnostics or symbolic debug- 
ging, that the line number of the next source line is given by the constant and the 


current input file is named by the identifier. If the optional file name is absent the 
remembered file name does not change. 
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Grammar Summary 





This chapter provides a summary of the CH grammar. 


17 Appendix A: Grammar Summary 


This appendix is not part of the C+ reference manual proper and does not define 
C+ language features. 

This summary of C+ syntax is intended to be an aid to comprehension. It is 
not an exact statement of the language. In particular, the grammar described here 
accepts a superset of valid C+ constructs. Disambiguation rules ($6.8, §7.1, 
§10.1.1) must be applied to distinguish expressions from declarations. Further, 
access control, ambiguity, and type rules must be used to weed out syntactically 
valid but meaningless constructs. 


17.1 Keywords 


New context-dependent keywords are introduced into a program by typedef 
(§7.1.3), class (§9), enumeration (§7.2), and template (§14) declarations. 


class-name: 
identifier 


enum-name;: 
identifier 


typedef-name: 
identifier 


Note that a typedef-name naming a class is also a class-name (§9.1). 
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17.2 Expressions 


expression: 
assignment-expression 
expression , assignment-expression 


assignment-expression: 
conditional-expression 
unary-expression assignment-operator assignment-expression 


assignment-operator: one of 
= Ske f=: "$a += -= >>= <<= f= ^s |= 


conditional-expression: 
logical-or-expression 
logical-or-expression ? expression : conditional-expression 


logical-or-expression: 
logical-and-expression 
logical-or-expression || logical-and-expression 


logical-and-expression: 
inclusive-or-expression 
logical-and-expression && inclusive-or-expression 


inclusive-or-expression: 
exclusive-or-expression 
inclusive-or-expression | exclusive-or-expression 


exclusive-or-expression: 
and-expression 
exclusive-or-expression ^ and-expression 


and-expression: 
equality-expression 
and-expression & equality-expression 


equality-expression: 
relational-expression 
equality-expression == relational-expression 
equality-expression ‘= relational-expression 


Section 17.2 Expressions 389 





relational-expression: 
shift-expression 
relational-expression < shift-expression 
relational-expression > shift-expression 5y 
relational-expression <= shift-expression 
relational-expression >= shift-expression 


shift-expression: 
additive-expression 
shift-expression << additive-expression 
shift-expression >> additive-expression 


additive-expression: 
multiplicative-expression 
additive-expression + multiplicative-expression 
adgitive-expression — multiplicative-expression 


multiplicative-expression: 
pm-expression 
myltiplicative-expression * pm-expression 
multiplicative-expression / pm-expression 
multiplicative-expression % pm-expression 


pm-expression: 
cast-expression 
pm-expression .* cast-expression 
pm-expression —>* cast-expression 


cast-expression: 
unary-expression 
( ftype-name ) cast-expression 


unary-expression: 
postfix-expression 
++  unary-expression 
-- unary-expression 
unary-operator cast-expression 
sizeof unary-expression 
sizeof ( type-name ) 
allocation-expression 
deallocation-expression 


unary-operator: one of 
t & + = ! ~ 
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allocation-expression: 


Sopi NEW placement, new'-type-name_ new-initializer,,, 


>So, New placement, ( type-name ) new-initializer n ` 


placement: 
( expression-list ) 


new-fype-name: 


type-specifier-list new-declarator yy, 


new-declarator: 
* cv-qualifier-list,,, new-declarator,,, 
complete-class-name :: * cv-qualifier-list,,, new-declarator, 


opt opt 
new'-declarator,,, [ expression ) 


new-initializer: 


( initializer-list,,, ) 


deallocation-expression: 
2 gp, Gelete cast-expression 
to, delete [ ] cast-expression 


postfix-expression: 
primary-expression 
postfix-expression [ expression ] 
postfix-expression ( expression-list,,, ) 
simple-type-name ( expression-list,,, ) 
postfix-expression . name 
postfix-expression -> name 
postfix-expression ++ 
postfix-expression -— 


expression-list: 
assignment-expression 
expression-list , assignment-expression 


primary-expression: 
literal 
this 
1: identifier 
:: operator-function-name 
:: qualified-name 
( expression ) 
name 
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name; 


Expressions 


identifier 
operator-function-name 
conversion-function-name 
~ class-name 
qualified-name 


qualified-name: 


literal: 


17.3 Declarations 


qualified-class-name :: name 


integer-constant 
character-constant 
floating-constant 
string-literal 


declaration: 


decl-specifiers,,, declarator-list 
asm-declaration 
function-definition 
template-declaration 


linkage-specification 


ee 


decl-specifier: 


storage-class-specifier 
type-specifier 
fet-specifier 

friend 

typedef 


decl-specifiers: 


decl-specifiers,,, decl-specifier 


storage-class-specifier: 


auto 
register 
static 
extern 


fet-specifier: 


inline 
virtual 


391 





392 Grammar Summary Chapter 17 


type-specifier: 
simple-type-name 
class-specifier 
enum-specifier 
elaborated-type-specifier 
const 
volatile 


simple-type-name: 
complete-class-name 
qualified-type-name 
char 
short 
int 
long 
signed 
unsigned 
float 
double 
void 


elaborated-type-specifier: 
class-key identifier 
class-key class-name 
enum enum-name 


class-key: 
class 
struct 
union 


qualified-type-name: 
typedef-name 
class-name :: qualified-type-name 


complete-class-name: 
qualified-class-name 
: qualified-class-name 


qualified-class-name: 
class-name 
class-name :: qualified-class-name 


enum-specifier: 
enum identifier,,, { enum-listo, ) 
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enum-list; 
enumerator 
enum-list , enumerator 


enumerator: 
identifier 
identifier = constant-expression 


constant-expression: 
conditional-expression 


linkage-specification: 
extern string-literal { declaration-list,., } 
extern string-literal declaration 


declaration-list: 
declaration 
declaration-list declaration 


asm-declaration: 
asm ( String-literal ) ; 


17.4 Declarators 


declarator-list: 
init-declarator 
declarator-list , init-declarator 


init-declarator: 
declarator initializer 


declarator: 
dname 
ptr-operator declarator 
declarator ( argument-declaration-list ) cv-qualifier-list y 
declarator [| constant-expression,, ] 
( declarator ) 


ptr-operator: 
* cy-qualifier-list,., 
& cy-qualifier-list,., 
complete-class-name :: * cv-qualifier-list,,, 


cv-qualifier-list: 
cv-qualifier cv-qualifier-list,.. 
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cv-qualifier: 
const 
volatile 


dname: 
name 
class-name 
~ class-name 
typedef-name 
qualified-type-name 


type-name: 

type-specifier-list abstract-declarator,,, 
type-specifier-list: 

type-specifier type-specifier-list,,, 


abstract-declarator: 

ptr-operator abstract-declarator,,, 
abstract-declarator,,, ( argument-declaration-list ) cv-qualifier-list,,, 
abstract-declarator,,, [| constant-expression 


( abstract-declarator ) 


opt ] 


argument-declaration-list: 
arg-declaration-liste, + + + opr 
arg-declaration-list , ... 


arg-declaration-list: 
argument-declaration 
arg-declaration-list , argument-declaration 


argument-declaration: 
decl-specifiers declarator 
decl-specifiers declarator = expression 
decl-specifiers abstract-declarator,,, 
decl-specifiers abstract-declarator,,, = expression 


function-definition: 
decl-specifiers,,, declarator ctor-initializer,,, fct-body 


fct-body: 
compound-statement 


initializer: 
= expression 
= { initializer-list top } 
( expression-list ) 
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initializer-list; 
expression 
initializer-list , expression 
{ initializer-list , Poet) z 


17.5 Class Declarations 


class-specifier: 
class-head { member-list.., } 


class-head: 
class-key identifier,,, base-speCopy 
class-key class-name base-speCcp, 


member-list: 
member-declaration member-list,., 
access-specifier : member-list,,, 


member-declaration: 
decl-specifiers,,, member-declarator-listy, i | 
function-definition ; op | 
qualified-name ; 


member-declarator-list: 
member-declarator 
member-declarator-list , member-declarator 


member-declarator: 
declarator pure-specifier,., 
identifier, : Constant-expression 


pure-specifier: 
= 0 


base-spec: 
: base-list 


base-list: | 
base-specifier 
base-list , base-specifier 


base-specifier: 
complete-class-name 
virtual access-specifier,, complete-class-name 
access-specifier virtual,,, complete-class-name 
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access-specifier: 
private 
protected 
public 


conversion-function-name: 
operator conversion-type-name 


conversion-type-name: 
type-specifier-list ptr-operator op 


ctor-initializer: 
: mem-initializer-list 


mem-initializer-list: 
mem-initializer 
mem-initializer , mem-initializer-list 


mem-initializer: - 
complete-class-name ( expression-list,,, ) 
identifier ( expression-list,,, ) 


operator-function-name: 
operator operator 


operator: one of 
new delete 


+ - * / % $ & | 2 
= < > += -= t= /= $s 
“= &= = << >> >>= <<= == l= 
<= >= && lI ++ -- ; ->* -> 
() () 


17.6 Statements 


statement: 
labeled-statement 
expression-statement 
compound-statement 
selection-statement 
iteration-statement 
jump-statement 
declaration-statement 


o= mmg 
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labeled-statement: 
identifier : statement 
case constant-expression : statement 
default : statement ox 


expression-Statement: 


expression, i 


compound-statement: 
{ statement-list,., } 


statement-list: 
Statement 
statement-list statement 


selection-statement: 
if ( expression ) statement 
if ( expression ) statement else statement 
Switch ( expression ) statement 


iferation-statement: 
while ( expression ) statement 
do statement while ( expression ) ; 
for ( for-init-statement expression y ; expression,,, ) Statement 


for-init-statement: 
expression-statement 
declaration-statement 


jump-statement: 
break ; 
continue ; 
return expression,,, 7 
goto identifier ; 


declaration-statement: 
declaration 


17.7 Preprocessor 


#define identifier token-string 
define identifier( identifier , ... , identifier ) token-string 


#include "filename" 
#include <filename> 
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#line constant "filename" sp 
#undef identifier 


conditional: 


if-part elif-parts,,, else-part,,, 


endif-line 


if-part: 
if-line text 


if-line: 

# if constant-expression 

# ifdef identifier 

# ifndef identifier 
elif-parts: 

elif-line text 

elif-parts elif-line text 
elif-line: 

# elif constant-expression ~~ 
else-part: 


else-line text 


else-line: 
# else 


endif-line: 
# endif 


17.8 Templates 


template-declaration: 
template < template-argument-list > declaration 


template-argument-list: 
template-argument 
template-argument-list , template argument 


template-argument: 
type-argument 
argument-declaration 


type-argument: 
class identifier 
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template-class-name: 
template-name < template-arg-list > 


template-arg-list: 
template-arg 
template-arg-list_, template-arg 


template-arg: 
expression 
type-name 


17.9 Exception Handling 


try-block: 
try compound-statement handler-list 


handler-list: 
handler handler-list,., 


handler: 
catch ( exception-declaration ) compound-statement 


exception-declaration: 
type-specifier-list declarator 
type-specifier-list abstract-declarator 
type-specifier-list 


throw-expression: 
throw expressiongo, 


exception-specification: 
throw ( Npe-list,, ) 


type-list: 
type-name 
type-list , type-name 
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Compatibility 


This chapter summarizes the evolution of C+ since the first edition of The C++ 
Programming Language and explains in detail the differences between G+ and 
C. Because the C language as described by the ANSI C Standard differs from 
the dialects of Classic C used up till now, we discuss the differences between 
C+ and ANSI C as well as the differences between C+ and Classic C. 


18 Appendix B: Compatibility 


This appendix is not part of the G+ reference manual proper and does not define 
C+ language features. 

C+ is based on C (K&R78) and adopts most of the changes specified by the 
ANSI C standard. Converting programs among C+, K&R C, and ANSI C may be 
subject to vicissitudes of expression evaluation. All differences between CH and 
ANSI C can be diagnosed by a compiler. With the following three exceptions, pro- 
grams that are both CH and ANSI C have the same meaning in both languages: 

In C, sizeof(’a‘) equals sizeof(int); in CH, it equals 
sizeof (char). 

In C, given 


enum e { A }; 


sizeof (A) equals sizeof (int); in CH, it equals sizeof (e), which need 
not equal sizeof (int). 

A structure name declared in an inner scope can hide the name of an object, 
function, enumerator, or type in an outer scope. For example, 
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int x[99]; 
void f() 
{ 
struct x { int a; }; 
sizeof(x); /* size of the array in C */ 
/* size of the struct in Ct+ */ 


) 


m The aim of CH was and is to be as close to C as possible. Historically, that has 
been complicated by there being no single obvious definition or implementation of C 
with which to be compatible. C+ compilers will still show anachronisms reflecting 
the various Classic C dialects. More important, though, CH relies on static type 
checking much more than C does, which necessitates some differences. These 
differences relate to the degree of type checking provided and to the central role of 
the class — the user-defined type — in CH. The remaining differences are deemed 
essential for the integrity of the CH type system. O 


18.1 Extensions 


This section summarizes the major extensions to C provided by CH. 


18.1.1 CH Features Available in 1985 


This subsection summarizes the extensions to C provided by CH in the 1985 ver- 
sion of this manual: 

The types of function arguments can be specified (§8.2.5) and will be checked 
(§5.2.2). Type conversions will be performed (§5.2.2). This is also in ANSI C. 

Single-precision floating point arithmetic may be used for float expressions; 
§3.6.1 and §4.3. This is also in ANSI C. 

Function names can be overloaded; §13. 

Operators can be overloaded; §13.4. 

Functions can be inline substituted; §7.1.1. 

Data objects can be const; §7.1.6. This is also in ANSI C. 

Objects of reference type can be declared; §8.2.2 and §8.4.3. 

A free store is provided by the new and delete operators; §5,3.3, §5.3.4. 

Classes can provide data hiding (§11), guaranteed initialization (§12.1), user- 
defined conversions (§12.3), and dynamic typing through use of virtual functions 
(§10.2). 

The name of a class or enumeration is a type name; §9. 

Any pointer can be assigned to a void* without use of a cast; §4.6. This is 
also in ANSI C. 

A declaration within a block is a statement; §6.7. 

Anonymous unions can be declared; §9.5. 
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18.1.2 C+ Features Added Since 1985 


This subsection summarizes the major extensions of C+ since the 1985 version of 
this manual: 

A class can have more than one direct base class (multiple inheritance); §10.1. 

Class members can be protected; §11. 

Pointers to class members can be declared and used; §8.2.3, §5.5. 

Operators new and delete can be overloaded and declared for a class; §5.3.3, 
§5.3.4, §12.5. This allows the ‘‘assignment to this’’ technique for class specific 
storage management to be removed to the anachronism section; §18.3.3. 

Objects can be explicitly destroyed; §12.4. 

Assignment and initialization are defined as memberwise assignment and initial- 
ization; §12.8. 

The overload keyword was made redundant and moved to the anachronism 
section; §18.3. 

General expressions are allowed as initializers for static objects; §8.4. 

Data objects can be volatile; §7.1.6. Also in ANSI C. 

Initializers are allowed for static class members; §9.4. 

Member functions can be static; §9.4. 

Member functions can be const and volatile; §9.3.1. 

Linkage to non-C program fragments can be explicitly declared; §7.4. 

Operators ->, ->*, and , can be overloaded; §13.4. 

Classes can be abstract; §10.3. 

Prefix and postfix application of ++ and —— on a user-defined type can be dis- 
tinguished. 

Templates (experimental); §14. 

Exception handling (experimental); §15. 

m The primary driving force in the evolution of C+ between 1985 and 1990 has 
been the desire to produce elegant and efficient libraries and to allow easy and safe 
composition of programs out of separately developed and separately compiled parts. 
o 


18.2 C+ and ANSI C 


In general, CH provides more language features and fewer restrictions than ANSI C 
so most constructs in ANSI C are legal in C+ with their meanings unchanged. 
The exceptions are: 

ANSI C programs using any of the C+ keywords 


asm catch class delete friend 
inline new operator private protected 
public template try this virtual 
throw 


as identifiers are not C+ programs; §2.4. 
Though deemed obsolescent in ANSI C, a C implementation may impose 
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Draconian limits on the length of identifiers; a CH implementation is not permitted 
to; §2.3. 

In CH, a function must be declared before it can be called; §5.2.2. 

The function declaration f () ; means that f takes no arguments (§8.2.5); in C 
it means that f can take any number of arguments of any type at all. Such use is 
deemed obsolescent in ANSI C. 

In ANSI C a global data object may be declared several times without using the 
extern specifier; in C+ it must be defined exactly once; §3.3. 

In CH, a class may not have the same name as a typedef declared to refer to a 
different type in the same scope; §9.1. 

In ANSI C a void* may be used as the right-hand operand of an assignment 
to or initialization of a variable of any pointer type; in CH it may not; §7.1.6. 

C allows jumps to bypass an initialization; CH does not. 

In ANSI C, a global const by default has external linkage; in CH it does not; 
§3.3, 

‘Old style’’ C function definitions and calls of undeclared functions are con- 
sidered anachronisms in CH and may not be supported by all implementations; 
§18.3.1. This is deemed obsolescent in ANSI C. 

A struct is a scope in CH (§3.2); in ANSI C a struct, an enumeration, or 
an enumerator declared in a struct is exported to scope enclosing the scope. 

Assignment to an object of enumeration type with a value that is not of that 
enumeration type is considered an anachronism in CH and may not be supported 
by all implementations; §7.2. ANSI C recommends a warning for such assign- 
ments. 

Surplus characters are not allowed in strings used to initialize character arrays; 
§8.4.2. 

The type of a character constant is char in CH (§2.5.2) and int in C. 

The type of an enumerator is the type of its enumeration in CH (§7.2) and int 
in C. 

In addition, the ANSI C standard allows conforming implementations to differ 
considerably; this may lead to further incompatibilities between C and C+ imple- 
mentations. In particular, some C implementations may consider certain incompati- 
ble declarations legal. C+ requires consistency even across compilation boun- 
daries; §3.3. : 


18.2.1 How to Cope 


In general, a CH program uses many features not provided by ANSI C. For such a 
program, the minor differences of §18.2 don’t matter since they are dwarfed by the 
C+ extensions. Where ANSI C and CH need to share header files, care must be 
taken so that such headers are written in the common subset of the two languages. 
No advantage must be taken of CH specific features such as classes, overload- 
ing, and so on. 
A name should not be used both as a structure tag and as the name of a 
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different type. 

A function f taking no arguments should be declared f (void) and not simply 
£(). 

Global consts must be declared explicitly static or extern. 

Conditional compilation using the C+ predefined name __ cplusplus may 
be used to distinguish information to be used by an ANSI C program from infor- 
mation to be used by a C+ program. 

Functions that are to be callable from both languages must be explicitly 
declared to have C linkage. 


18.3 Anachronisms 


The extensions presented here may be provided by an implementation to ease the 
use of C programs as CH programs or to provide continuity from earlier CH 
implementations. Note that each of these features has undesirable aspects. An 
implementation providing them should also provide a way for the user to ensure 
that they do not occur in a source file. A C+ implementation is not obliged to 
provide these features. 


B It is easy to deem an undesirable feature an anachronism and remove it from the 
reference manual; it is an entirely different matter to modify a compiler to disallow a 
feature that a programmer relies on. The problem of how to manage transitions from 
old code (often C code) to a more up-to-date implementation is often handled like 
this: 

[1] Release N contains the old feature (only). 

[2] Release N+! issues a warning for uses of the old feature and provides the 

alternative new feature. 

(3] Release N+2 provides the alternative new feature (only). 
Sometimes it takes more than two releases to fade out a feature, so this process may 
be extended. O 


The word overload may be used as a decl-specifier (§7) in a function 
declaration or a function definition. When used as a decl-specifier, overload is a 
reserved word and cannot also be used as an identifier. 

_ The definition of a static data member of a class for which initialization by 
default to all zeros applies (§8.4, §9.4) may be omitted. 

An old style (that is, pre-ANSI C) C preprocessor may be used. 

An int may be assigned to an object of enumeration type. 

The number of elements in an array may be specified when deleting an array of 
a type for which there is no destructor; §5.3.4. 

A single function operator++() may be used to overload both prefix and 
postfix ++ and a single function operator--() may be used to overload both 
prefix and postfix --; §13.4.6. 
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18.3.1 Old Style Function Definitions 
The C function definition syntax 


old-function-definition: 


decl-specifiers,,, old-function-declarator declaration-list,,, fct-body 


opt 


old-function-declarator: 
declarator ( parameter-list,,, ) 


parameter-list: 
identifier 
parameter-list , identifier 


For example, 
max(a,b) int b; { return (a<b) ? b: a; } 


may be used. If a function defined like this has not been previously declared its 
argument type will be taken to be (...), that is, unchecked. If it has been 
declared its type must agree with that of the declaration. 

Class member functions may not be defined with this syntax. 


18.3.2 Old Style Base Class Initializer 


In a mem-initializer(§12.6.2), the class-name naming a base class may be left out 
provided there is exactly one immediate base class. For example, 


Class D : public B { 

Lita 

Diante ers Gh) suse ay) 
}; 


causes the B constructor to be called with the argument i. 


18.3.3 Assignment to this 


Memory management for objects of a specific class can be controlled by the user i 
by suitable assignments to the this pointer. By assigning to the this pointer 
before any use of a member, a constructor can implement its own storage alloca- 
tion. By assigning a zero value to this, a destructor can avoid the standard 
deallocation operation for objects of its class. Assigning a zero value to this in a 
destructor also suppressed the implicit calls of destructors for bases and members. 
For example, 
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class Z { 
int z[10]; 
Z() { this = my_allocator( sizeof(Z) ); } 
~Z() { my_deallocator( this ); this = 0; } 
); 


On entry into a constructor, this is nonzero if allocation has already taken 
place (as it will have for auto, static, and member objects) and zero otherwise. 

Calls to constructors for a base class and for member objects will take place 
(only) after an assignment to this. If a base class’s constructor assigns to this, 
the new value will also be used by the derived class’s constructor (if any). 

Note that if this anachronism exists either the type of the this pointer cannot 
be a *const or the enforcement of the rules for assignment to a constant pointer 
must be subverted for the this pointer. 


18.3.4 Cast of Bound Pointer 


A pointer to member function for a particular object may be cast into a pointer to 
function, for example, (int (*) ())p->f£. The result is a pointer to the function 
that would have been called using that member function for that particular object. 
Any use of the resulting pointer is — as ever — undefined. 


18.3.5 Nonnested Classes 


Where a class is declared within another class and no other class of that name is 
declared in the program that class can be used as if it was declared outside its 
enclosing class (exactly as aC struct). For example, 


struct S.{ 
struct T { 
int a; 
}; 
int b; 


}: 


struct T x; // meaning ‘S::T x;’ 
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of bit-field restriction 184 
of constructor 265 
of member 156 
of overloaded function 55, 327 
of qualified name 55 
of reference 56 
address-of operator 54 
adjusting 
access rationale 246-247 
base class member access 244 
aggregate 151 
alert 9 
Algol60 231 
Algol68 83, 153 
alignment 
of array 68 
of bit-field 184 
of bit-field, implementation dependency 
184 
of class 68 
of class member 68 
of floating point type 24 
of integral type 23 
requirement, implementation dependency 
23 


restriction 68 ; 
allocation 59 i 

access specifier and member 242 | 
efficiency, array 60 
efficiency, class object 57 
empty class 164 
implementation dependency 173, 241 
implementation dependency base class 

198 
implementation dependency bit-field 

184-185 
new, storage 58 


allocation-expression 58 
ambiguity 


access control and 206 
base class member 202 
class conversion 206 
class name 167 
declaration type 96 
declaration versus cast 131 
declaration versus expression 93 
derived class and 206 
destructor versus one’s complement 
operator 279 
detection, overloaded function 312 
example, user-defined conversion 288 
function declaration 150 
if-else 85 
inheritance and 206 
member access 202 
multiple inheritance and 206 
overloading resolution 313 
overloading resolution and ellipsis 325 
overloading resolution conversion and 313 
parentheses and 62 
pointer conversion 36 
pointer to member conversion 39 
reference conversion 38 
resolution, scoping 203 
user-defined conversion 275 
~ 279 
anachronism 405 
C function definition 406 
assignment to this 406 
cast of pointer to member 407 
free store and constructor 406 
free store and destructor 406 
memory management 406 
nonnested class 407 
old style base class initializer 406 
old style function definition 406 
overload keyword 405 
pointer to member conversion 407 
scope of nested class 407 
this and constructor 406 
this and destructor 406 
AND 
operator, bitwise 7 
operator, logical 77 
operator, side effects and logical 77 
Annemarie 325 
anonymous 
union 182 
union access control 183 
union, extension to C 402 
union, global 182 
union rationale, global 183 
union restriction 183 
ANSI 
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C and pointer conversion 36 
Cand shared headers 120, 404 
C const initialization, difference from 
110 
C headers 7 
C implementation dependency, difference 
from 404 
C pointer to function conversion, 
difference from 69 
C preprocessing 380 
C standard 2 
C summary, compatibility with 403 
argc 19 
argument 145 
class object as 288 
const reference 308 
conversion 50, 139 
declaration 138-139 
declaration, scope of 143 
default — see default argument 
evaluation, order of 50 
evaluation, undefined order of 50 
example, unnamed 145 
initialization, formal 49 
list efficiency, variable 118 
list, empty 133 
list example, variable 140, 146 
list, variable 50, 138, 146-147 
matching — see overloading resolution 
null preprocessing 381 
passing 49 
passing, reference and 154 
pointer 145 
reference 49, 134, 145 
scope of formal 15 
temporary 308 
to constructor, undefined 61 
to new, zero 59 
tokenless preprocessing 381 
type checking 49 
type conversion 270 
type, unknown 138 
undefined null preprocessing 381 
undefined tokenless preprocessing 381 
unnamed 140 
void 138 
argument-declaration 138 
arguments 
to inline function, order of evaluation 102 
tomain() 19 
to main (), implementation dependency 
19 
argv[] 19 
arithmetic 
conversion 34, 40 
conversion mules 40 
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exception 46 
exception, implementation dependency 46 
extension to C single precision 402 
pointer 72 
single precision floating point 33 
type 24 
unsigned 23 
array 
alignment of 68 
allocation efficiency 60 
bound, undefined access outside 73, 76, 
172 
const 108 
constructor and 61 
declaration 136 
declarator [] 136 
declarator, multidimensional 136 
default constructor and 61 
delete 64 
delete and 283 
efficiency 137 
example 136 
indexing — see subscripting 
initialization 151 
member 172 
member initialization 290 
member initialization, const 289-290 
member initialization, static 289 
multidimensional 136 
new 59 
new and 283 
of class objects and constructor 289 
of class objects and default constructor 
289 
of class objects and new 60 
of class objects initialization 152, 289 
of class objects rationale 60 
of reference 154 
order of execution, constructor and 265 
order of execution, destructor and 277 
overloading and pointer versus 309 
pointer conversion 36 
size, default 136 
sizeof 58 
storage of 137 
subscripting — see subscripting 
type 24 
volatile 111 
arrow operator — see class member access 
operator 
ASCII character set 371 
asm 
declaration 115 
implementation dependency 115 
assembler 115 


assignment 


and initialization, overloaded 285 
and value 79 
base class object 79 
const pointer 79 
conversion by 80 
derived class object 79 
efficiency, overloaded 192 
expression 79 
extension to C memberwise 403 
member 296 
memberwise 334 
of class object 297 
of derived class to base class 297 
operator 79, 285, 295 
operator access, default 296 
operator, default 334 
operator, default 295-296, 298 
operator, efficiency and user-defined 301 
operator example, overloaded 335 
operator, overloaded 334 
operator restriction, default 296 
operator summary of characteristics 306 
operator, temporary and user-defined 301 
pointer to const 79 
pointer to member 80 
pointer to volatile 79 
prohibiting 304 
reference 154 
to base class rationale 297 
to class object 79 
to pointer 79 
to pointer to member 79 
to pointer to member, zero 79 
to pointer, zero 79 
to reference 80 
to this anachronism 406 
versus initialization 80-81, 285-286 
volatile pointer 79 
assignment-expression 79 
assignment-operator 79 
assumptions for exception handling 355 
atexit() 21 
auto 
destruction of 91 
initialization 91-92 
object initialization 149 
restriction 97 
specifier 97 
storage class 21 
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backslash 
and line continuation 369-370 
character 9 

backspace 9 


base 
class 195-197 
class access 242 
class allocation, implementation 
dependency 198 
class and cast 221 
class and virtual function 232 
class, assignment of derived class to 297 
class cast 68 
class, cast to 199-200 
class, constructor and 262 
class constructor order of execution 265 
class conversion 223-224 
class conversion, pointer to 212 
class destructor order of execution 277 
class, direct 197-198 
class, indirect 197-198 
class initialization 290-291 
class initialization, order of 292 
class initialization rationale 290 
class initializer 145 
class initializer anachronism, old style 406 
class member access 196 
class member access, adjusting 244 
class member ambiguity 202 
class object, assignment 79 
class, pointer comparison 222 
class pointer conversion 36 
class, private 242 
class, public 242 
class rationale, assignment to 297 
class, reference to 38 
class virtual — see virtual base class 
of integer constant 8 
base-list 195 
base-specifier 195 
Ben 310 
binary 
operator example, overloaded 333 
operator, interpretation of 333 
operator, overloaded 333 
binding 
— see virtual function, dynamic 
default argument 142 
bit-field 184 
address of 184 
alignment of 184 
allocation, implementation dependency 
184-185 
declaration 184 
efficiency, sign of 184 
implementation dependency alignment of 
184 
implementation dependency sign of 184 
layout 184 > 
restriction 184 
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restriction, address of 184 
restriction, pointer to 184 
type of 184-185 
unnamed 184 
use efficiency 185 
zero width of 184 
bitwise 
AND operator 76 
exclusive OR operator 77 
inclusive OR operator 77 
operator 76 
block 
initialization in 91 
scope — see local scope 
statement {} 84 
structure 91 
body, function 145 
bound 
pointer to member function, undefined 
407 
undefined access outside array 73, 76, 172 
break statement 89 
built-in type — see fundamental type 
byte 56 
C 
define, Classic 383 
else, Classic 385 
endif, Classic 385 
#if, Classic 385 
#ifndef, Classic 385 
include, Classic 384 
include file name, Classic 384 
#include file name combining tokens, 
Classic 384 
line, Classic 385 
undef, Classic 384 
ANSI 1 
Classic 1 
_ cplusplus, Classic 383 
and integral promotion, Classic 32 
and pointer conversion, ANSI 36 
and shared headers, ANSI 120, 404 
anonymous union, extension to 402 
character constant, difference from 9 
class, extension to 402 
class name, difference from 26 
comment, difference from 6 
conditional compilation, Classic 385 
const, extension to 402 
const initialization, difference from ANSI 
110 
dangerous extension to 405 
declaration statement, extension to 402 
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definition, difference from 14 

delete, extension to 402 

destructor, extension to 403 

escape sequence, difference from 10 

expression evaluation, difference from 401 

extension to 1, 402-403 

file inclusion, Classic 384 

floating point accuracy, difference from 46 

function declaration, difference from 404 

function definition anachronism 406 

function, overloading 121 

headers, ANSI 7 

implementation dependency #include 
file name, Classic 384 

implementation dependency #include 
nesting limit, Classic 384 

implementation dependency #indef 
nesting limit, Classic 385 

implementation dependency conditional 
compilation nesting limit, Classic 385 

implementation dependency, difference 
from ANSI 404 

implementation dependency extension to 
405 

inclusion source file, Classic 384 

initialization and goto, difference from 
404 

inline function, extension to 402 

jump past initialization, difference from 
92, 404 

linkage, compatibility with 99 

linkage, difference from 404 

linkage to 116 

macro preprocessing, Classic 383 

memberwise assignment, extension to 403 

memberwise initialization, extension to 
403 

multiple inheritance, extension to 403 

name space, compatibility with 167 

name space, difference from 26, 404 

nested class, difference from 186 

new, extension to 402 

object layout, compatibility with 165 

overloading delete, extension to 403 

overloading, extension to 402 

overloading new, extension to 403 

pointer to function conversion, difference 
from ANSI 69 

pointer to member, extension to 403 

preprocessing, ANSI 380 

preprocessing, Classic 380 

preprocessing and 5, 370 

preprocessing comment, Classic 384 

protected, extension to 403 

rationale, scoping difference from 402 

reference type, extension to 402 


scope, difference from 401 
single precision arithmetic, extension to 
402 
sizeof, difference from 401 
source file inclusion, Classic 384 
standard, ANSI 2 
string literal, difference from 11 
summary, compatibility with 401 
summary, compatibility with ANSI 403 
token #finclude file name, Classic 384 
token replacement, Classic 383 
type checking, extension to 402 
type equivalence, difference fram 139, 166 
undeclared function, difference from 50 
user-defined type, extension to 402 
void* conversion, difference from 36 
void* pointer type extension to 402 
volatile, extension to 403 
with Classes 2 
C++ 
design of 3 
evolution of 1-2 
rationale, evolution of 3, 403 
call 
- see also function call, member function 
call, overloaded function call, virtual 
function call 
by reference 49 
by value 49 
operator function 330 
carriage return 9 
case of identifier, implementation 
dependency 6 
case label 84-86 
cast 
ambiguity, declaration versus 131 
base class 68 
base class and 221 
class object 70 
const 70 
const and 109 
derived class 68 
derived class and 221 
enumand 114 
implementation dependency pointer to 
function 69-70 
integer to pointer 68 
Ivalue 69 
multiple inheritance and 221 
of pointer to member anachronism 407 
operator 54, 67, 130 
pointer to function 69 
pointer to integer 67 
pointer to member 70 
pointer to pointer 68 
reference 69 


to base class 199-200 
to undefined class 68 
virtual base class and 227 
cast-expression 67 
casting 52, 67 
example 52, 67 
pointer to volatile 71 
catch 354-355 
change 
to const object, implementation 
dependency 71 
to const object, undefined 109 
to string literal, undefined 10 
char 
constant, implementation dependency 
value of 10 
efficiency, sign of 23 
implementation dependency sign of 22-23 
integer conversion 31 
integer, implementation dependency 32 
type 22 
type, signed 22 
type specifier 111 
type, unsigned 22 
character 
array initialization 153 
constant 9 
constant, difference from C 9 
constant, preprocessing 370 
constant, sizeof 9 
constant, type of 9 
set, ASCII 371 
set, ISO 371 
signed 22 
string 10 
character-based, preprocessing 380 
charizing 382 
class 24, 163 
abstract 214 
access and friend 250 
alignment of 68 
allocation, empty 164 
anachronism, nonnested 407 
and type 163 
as interface 191 
base — see base class 
cast to undefined 68 
concept 165 
constant 271 
constructor and abstract 215 
conversion 270 
conversion ambiguity 206 
declaration 164, 169, 191 
declaration example 172 
declaration, forward 167, 196 
declaration, friend 168 
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declaration name hiding 166 

declaration rationale 174 

declaration, scope of 166 

declaration syntax summary 395 

declaration {} 163 

definition 164 

definition 14, 18 

derived — see derived class 

descriptor 213 

example, friend 168 

extension toC 402 

friend 249 

implementation efficiency 192 

implementation rationale 191 

lattice - see DAG 

linkage of 18 

linkage specification 117 

local — see local class 

member - see also member 

member access 53 

member access operator 53 

member access operator example, 
overloaded 337 

member access operator summary of 
characteristics 306 

member, alignment of 68 

member declaration 169 

member function 173 

member initialization 150 

member semantics 53 

member, static 22 

member storage class 22 

member syntax 53 

member, type of 55 

meta 212 

name 130 

Name ambiguity 167 

name as type declaration 166 

name declaration 14 

name, difference from C 26 

name, elaborated 112, 167-168 

name encoding 123 

name example, typedef 169 

name name space 26 

name, point of declaration 168 

name redefinition 189 

name, scope of 166 

Name, scope resolution operator used with 
16 

name, typedef 106-107, 169 

nested — see nested class 

object allocation efficiency 57 

object as argument 288 

object, assignment of 297 

object, assignment to 79 

object cast 70 
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object, const 108-109, 177 

object copy 295 

object copy — see also copy constructor 

object copy efficiency 295 

object copy example 298 

object example, sizeof 57 

object initialization 151, 284 

object initialization — see also constructor 

object initialization example 288 

object layout 173, 198, 217-220, 225 

object, member 171 

object, operations on 164 

object return type 51, 288 

object, sizeof 57 

object, volatile 111 

objects and constructor, array of 289 

objects and default constructor, array of 
289 

objects and new, array of 60 

objects initialization, array of 152, 289 

objects rationale, array of 60 

partially specified 175 

pointer to abstract 214 

scope 15 

scope of enumerator 115 

scope of friend 168 

sizeof, empty 164 

template 343 

type restriction, member of 289 

unnamed 164 

use, empty 164 

use, unnamed 164 

with constructor, ellipsis and 298 

class 

type specifier 111 

versus struct 165 

versus union 165 

Classic 

C1 

C define 383 

C else 385 

C endif 385 

C if 385 

C #ifndef 385 

C #include 384 

C #include file name 384 

C #include file name combining tokens 
384 

C fline 385 

C fundef 384 

C__ cplusplus 383 

C and integral promotion 32 

C conditional compilation 385 

C file inclusion 384 

C implementation dependency #include 
filename 384 


C implementation dependency #include 
nesting limit 384 
C implementation dependency #indef 
nesting limit 385 
C implementation dependency conditional 
compilation nesting limit 385 
C inclusion source file 384 
C macro preprocessing 383 
C preprocessing 380 
C preprocessing comment 384 
C source file inclusion 384 
C token #include file name 384 
C token replacement 383 
class-key 111, 164 
class-name 163 
class-specifier 163 
combining 
tokens, #include file name 376 
tokens, Classic C #include file name 384 
comma 
operator 81 
operator, side effects and 81 
comment 
pei HP AS 
// 6 
Classic C preprocessing 384 
difference from C 6 
Preprocessing 370 
comparison 
and portability, pointer 75 
base class, pointer 222 
derived class, pointer 222 
implementation dependency pointer 75 
pointer 74-75 
pointer to function 74 
undefined pointer 73, 75 
void* pointer 74 
compatibility 
integral promotion 32 
preprocessing 380 
with ANSI C - see also difference from 
ANSI C 
with ANSI C summary 403 
with C — see also difference from C 
with C linkage 99 
with C name space 167 
with C object layout 165 
with C summary 401 
compiler control line - see preprocessing 
directive 
complete object 293 
complete-class-name 112 
compound statement 84 
compound-statement 84 
compromise, name space 26 
computation floating point accuracy 35, 46 
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concatenation 
preprocessing 382 
string 10 
string literal 370 
undefined string literal 11 
concept, class 165 
conditional 
compilation 376, 383 
compilation, Classic C 385 
compilation nesting limit, Classic C 
implementation dependency 385 
compilation nesting limit, implementation 
dependency 378 
compilation, preprocessing 383 
expression operator 78 
conditional 376 


consistency 
example, linkage 98 
linkage 18, 98 


linkage specification 117 
rationale, linkage 99 
translation unit and 404 

type declaration 18 
*const example 133 
const 

and cast 109 

array 108 

array member initialization 289-290 
assignment, pointer to 79 

cast 70 

class object 108-109, 177 
constructor and 178, 262 
conversion 37 

declarator 133 

destructor and 178, 277 
example 133 

extension to C 402 
initialization 108, 110, 149 
initialization, difference from ANSI C 110 
initialization, pointer to 149 
linkage of 17, 98, 110 

meaning of 109 

member function 177 

member initialization 291 
object, implementation dependency change 

to 71 

object storage class 110 

object, undefined change to 109 
operand 46 

overloading and 308 

pointer assignment 79 

pointer conversion 37 

pointer initialization 149 
reference 154 

reference argument 308 
reference rationale 155 
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type 108 
versus preprocessing macro 380 
constant 8, 24, 47 
base of integer 8 
character 9 
class 271 
decimal 8 
difference from C character 9 
double 10 
enumeration 113 
expression 81 
float 10 
floating point 10 
hexadecimal 8 
implementation dependency type of 
integer 8 
implementation dependency value of char 
10 
implementation dependency value of 
multicharacter 9 
integer 8 
long 8 
long double 10 
multicharacter 9 
octal 8 
pointer declaration 133 
pointer example 133 
sizeof character 9 
type of character 9 
type of floating point 10 
type of integer 8 
unsigned 8 
constant-expression 81 
constructor 262 
access control 304 
access, default copy 296 
address of 265 
anachronism, free store and 406 
anachronism, this and 406 
and abstract class 215 
and access, copy 287 
and array 61 
and array order of execution 265 
and base class 262 
and const 178, 262 
and initialization 284 
and initialization example 284 
and member function 267 
and member function call 294 
and new 60-61, 262, 282 
and new, implementation dependency 61 
and new, private 305 
and new, protected 305 
and return 90 
and static objects order of execution 
289 
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and virtual base class 262 
and virtual function 232 
and virtual function call 294 
and virtual function table 262 
and volatile 178, 262 
array of class objects and 289 
call, explicit 266 
call, implicit 262, 271 
conversion by 271 
conversion by — see also user-defined 
conversion 
copy 264, 268, 295 
default - see default constructor 
default copy 285, 287, 295-296, 298 
definition 145 
ellipsis and class with 298 
example 266 
example, private copy 287 
exception handling 358 
for temporary 267 
inheritance of 263 
local object 22 
name encoding 123 
order of execution, base class 265 
order of execution, member 265 
private 304 
programming technique, pointer to 266 
programming technique, virtual 262 
protected 304 
purpose of 262 
rationale, copy 264 
restriction 262, 265 
restriction, default copy 296 
restriction rationale 265 
side effects and 267 
summary of characteristics 306 
type of 265 
undefined argument to 61 
union 181 
use 271 
continuation, preprocessing line 370 
continue 
in for statement 88 
statement 89-90 
control line — see preprocessing directive 
conversion 
— see also type conversion 
ANSI C and pointer 36 
Cray 42 
VAX 41 
ambiguity, class 206 
ambiguity example, user-defined 288 
ambiguity, pointer 36 
ambiguity, pointer to member 39 
ambiguity, reference 38 
ambiguity, user-defined 275 


anachronism, pointer to member 407 

and ambiguity, overloading resolution 313 

and name hiding, user-defined 275 

argument 50, 139 

arithmetic 34, 40 

array pointer 36 

base class 223-224 

base class pointer 36 

by assignment 80 

by constructor 271 

char integer 31 

class 270 

const 37 

const pointer 37 

derived class 224 

derived class pointer 36 

difference from ANSI C pointer to function 
69 

difference from C void* 36 

example, user-defined 273 

explicit type — see casting 

floating point integer 33, 40 

function — see also user-defined 
conversion 

function summary of characteristics 306 

implementation dependency floating point 
33 

implementation dependency floating point 
integer 34 

implementation dependency integer 33 

implementation dependency pointer 
integer 67-68 

implicit 31, 47, 270 

implicit user-defined 274, 287 

inheritance and 224 

inheritance of user-defined 273 

integer 33, 41 

integer to pointer 72 

lvalue 31 

multiple inheritance and 223 

null pointer 36-37 

operator 47, 272 

out of range value, undefined 33 

overloaded function and standard 326 

overloading resolution and 317 

overloading resolution and pointer 324, 
328 

overloading resolution and standard 318, 
322 

overloading resolution and user-defined 
319, 325-326 

pointer 37 

pointer 35 

pointer to base class 212 

pointer to derived class 212 

pointer to function 36 


pointer to integer 72 
pointer to member 38-39 
pointer to member void* 40 
pointer to pointer 72 
rationale, overloading resolution and 
pointer 329 
reference 38 
return type 90 
rules, arithmetic 40 
rules, type 34 
safe 40 
safe floating point 33 
safe floating point integer 34 
safe integer 33 
signed 33 
signed unsigned integer 33 
standard 31 
to fundamental type — see user-defined 
conversion 
type of 273 
unsigned 33 
user-defined 47, 270-272 
virtual user-defined 274 
void* pointer 36 
volatile pointer 37 
zero pointer 36 
conversion-function-name 272 
copy 
class object 295 
constructor 264, 268, 295 
constructor access, default 296 
constructor and access 287 
constructor, default 285, 287, 295-296, 298 
constructor example, private 287 
constructor rationale 264 
constructor restriction, default 296 
efficiency, class object 295 
example, class object 298 
copying 
fundamental type 192 
prohibiting 304 
user-defined type 192 
user-defined type, access control and 304 
__ cplusplus 379, 405 
Classic C 383 
example 120 
Cray, conversion 42 
ctor-initializer 291 
cv-qualifier 130 
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multiple inheritance 198, 200-201, 204, 206 
nonvirtual base class 201 
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virtual base class 200-201, 204, 206, 292 


dangerous extension to C 405 


data 
abstraction 165 
hiding 256 
member — see member 
__DATE_ 379 
deallocation — see delete 
deallocation-expression 62 
debuggers 
and exception handling 358 
and overloaded function 125 
decimal constant 8 
declaration 13, 95 
:, field 184 
access 244 
ambiguity, function 150 
argument 138-139 
array 136 
as definition 98 
asm 115 
bit-field 184 
class 164, 169, 191 
class member 169 
class name 14 
class name as type 166 
class name, point of 168 
consistency, type 18 
constant pointer 133 
default argument 141 
definition versus 13 
ellipsis in function 50, 138, 147 
empty 96 
enumerator, point of 17 
example 14, 139 
example, function 140 
example, nested class 187 
example, point of 139 
extern 13 3 
extern reference 154 
forward 99 
forward class 167, 196 
friend class 168 
friend member function 175 
function 13, 138 
function member 173 
function template 346 
hiding — see name hiding 
in for, scope of 88 
in for statement 88 
in switch statement 86 
inline member function 175 
list, scope of 144 
local class 188 
matching, overloaded function 310 
member 169 
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multiple 14, 18 

name 13, 96 

name hiding, class 166 

name hiding, function 144 
name, point of 16 

nested class 185 

overloaded name and access 246 


overloaded name and friend 249 


parentheses in 131-132 
pointer 133 
rationale, class 174 
reference 134 
register 97 
scope of argument 143 
scope of class 166 
specifier 96 
statement 83, 91 
statement, extension to C 402 
statement restriction 85, 87 
static member 13 
static member function 175 
storage class 97 
syntax summary 39] 
syntax summary, class 395 
template 347 
template class 347 
template function 347 
type 131 
type ambiguity 96 
typedef 14 
typedef as type 105 
typedef function 108 
versus cast ambiguity 131 
versus expression ambiguity 93 
virtual member function 175 
{}, class 163 
{}, enum 113 
declaration 95 
declaration-list 116 
declaration-statement 91 
declarator 95, 129 
&, reference 134 
(), function 138 
*, pointer 132 
::*, pointer to member 135 
{), array 136 
const 133 
example 131 
meaning of 131 
multidimensional array 136 
syntax rationale 132 
syntax summary 393 
volatile 133 
declarator 129 
declarator-list 129 
decl-specifier 96 


decoding, function name 125 


decrement 
operator 54, 56 
operator, overloaded 338 


default 


access control 241 
argument and name hiding 142 
argument binding 142 
argument declaration 141 
argument evaluation 142 
argument example 141-142 
argument, overloaded operator and 331 
argument, overloading and 144 
argument, overloading resolution and 316 
argument rationale 144 
argument, scope of 142 
argument type checking 142 
array size 136 
assignment operator 334 
assignment operator 295-296, 298 
assignment operator access 296 
assignment operator restriction 296 
constructor 263-264, 289, 295 
constructor and array 61 
constructor and initialization 284 
constructor and new 61 
constructor, array of class objects and 289 
copy constructor 285, 287, 295-296, 298 
copy constructor access 296 
copy constructor restriction 296 
destructor 277, 283 
initialization 150 
member access, struct 165 
member access, union 165 
type int 111 

default label 84-86 

fdefine 372, 380 
Classic C 383 
directive 379 

defined operator 377 

definition 
and initialization 98 
class 14, 18 
class 164 
constructor 145 
declaration as 98 
difference from C 14 
enumerator 14, 18 
enumerator point of 114 
example 14 
example, function 145 
function 14, 18 
function 145 
function template 346 
inline member function 18 
member 174 


member function 174-175, 178 
multiple 14 
object 14, 18 
pure virtual function 214 
scope of function 18 
static member 180 
template class 347-348 
template function 347-348 
versus declaration 13 
virtual function 209 
delete 62, 64 
and array 283 
array 64 
destructor and 64, 278 
efficiency 65 
example 63, 283 
example, destructor and 284 
example, scope of 284 
extension to C 402 
extension to C overloading 403 
overloading and 283 
private destructor and 305 
protected destructor and 305 
rationale, type of 281 
summary of characteristics 306 
type of 283 
undefined 63, 65 
undefined value 63 
zero pointer 63 
deleted object, undefined 63 
demotion 
implementation dependency integer 33 
integer 33 
dereference, null pointer 176 
dereferencing 46 
~ see also indirection 
derivation — see inheritance 
derived 
class 195 
class and ambiguity 206 
class and cast 221 
class cast 68 
class conversion 224 
class conversion, pointer to 212 
class example 196 
class layout 219-220 
class, most 293 
class object, assignment 79 
class, overloading and 310 
class, pointer comparison 222 
class pointer conversion 36 
class to base class, assignment of 297 
type 24 
descriptor, class 213 
design of C++ 3 
destruction 
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of auto 91 

of local static 92 

of local variable 91 

of temporary efficiency 268 

of temporary, implementation dependency 
268 


destructor 276 
access control 304-305 
anachronism, free store and 406 
anachronism, this and 406 
and array order of execution 277 
and const 178, 277 
and delete 64, 278 
and delete example 284 
and delete, private 305 
and delete, protected 305 
and exit from scope 89 
and fundamental type 280 
and member function 278 
and member function call 294 
and placement of object 279 
and static objects order of execution 

289 
and virtual function call 294 
and volatile 178, 277 
call example, expliat 278 
call, explicit 278-279 
call, implicit 278 
call, undefined 92 
default 277, 283 
efficiency, virtual 278 
example, virtual 277 
exception handling 358 
extension to C 403 
for temporary 267 
inheritance of 277 
local object 22 
name encoding 123 
order of execution 277 
order of execution, base class 277 
order of execution, member 277 
private 305 
program termination and 278 
protected 305 
rationale 276, 278 
restriction 276, 278 
side effects and 267 
static object 21 
summary of characteristics 306 
union 181 
versus one’s complement operator 
ambiguity 279 
virtual 277 

difference 
from ANSI C const initialization 110 
from ANSI C implementation dependency 
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from ANSI C pointer to function 
conversion 69 
from C character constant 9 
from C class name 26 
from C comment 6 
from C definition 14 
from C escape sequence 10 
from C expression evaluation 401 
from C floating point accuracy 46 
from C function declaration 404 
from C initialization and goto 404 
from C jump past initialization 92, 404 
from C linkage 404 
from C name space 26, 404 
from C nested class 186 
from C rationale, scoping 402 
from C scope 401 
from C sizeof 401 
from C string literal 11 
from C type equivalence 139, 166 
from C undeclared function 50 
from C void* conversion 36 
direct base class 197-198 
directed acyclic graph - see DAG 
directive 
error preprocessing 378 
null preprocessing 379 
pragma preprocessing 378 
preprocessing 369 
distinct string 10 
division 
by zero, undefined 46, 72 
implementation dependency 72 
operator 72 
dname 130 
do statement 87 
dominance 
DAG 205 
virtual base class 204 
dot operator — see class member access 
operator 
double quote 9 
double 
constant 10 
type 23 
type specifier 111 
dynamic 
binding — see virtual function 
initialization 19 
initialization programming technique 20 
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E suffix 10 
efficiency 3 
and user-defined assignment operator 301 


array 137 
array allocation 60 
bit-field use 185 
class implementation 192 
class object allocation 57 
class object copy 295 
delete 65 
destruction of temporary 268 
ellipsis and 118 
exception handling 357 
friend function 248 
function call 118 
inline function 380 
inline virtual 209 
member access 220 
member function call 177 
new 60, 65 
overloaded assignment 192 
reference 154 
register 103 
right shift operator 74 
sign of bit-field 184 
sign of char 23 
sizeof type 42 
template 342 
variable argument list 118 
virtual destructor 278 
virtual function call 209 
elaborated 
class name 112, 167-168 
enum name 112 
type specifier — see elaborated class name 
elaborated-type-specifier 111 
telif 377 
elif-line 377 
elif-parts 377 
elimination of temporary 267, 299-301, 303 
ellipsis 
ambiguity, overloading resolution and 325 
and class with constructor 298 
and efficiency 118 
example 140, 146 
in function declaration 50, 138, 147 
overloading resolution and 317, 319, 325 
use 146 
felse 377 
Classic C 385 
and tendif trailing tokens 383 
else 85 
else-line 377 
else-part 377 
empty 
argument list 138 
class allocation 164 
class sizeof 164 
class use 164 


declaration 96 
statement 84 
encapsulation 256 
encoding 
class name 123 
function name 122, 124 
member function 123 
fendif 377 
Classic C 385 
endif-line 377 
enum 
and cast 114 
declaration {} 113 
implementation dependency sizeof 114 
name, elaborated 112 
overloading and 309 
sizeof 114 
type of 113-114 
type specifier 111 
enumeration 113 
constant 113 
example 114 
typedef 107 
enumerator 
class, scope of 115 
definition 14, 18 
linkage of 18 
member 115 
point of declaration 17 
point of definition 114 
redefinition 114 
restriction 113 
value of 113 
enumerator 113 
environment, program 19 
equality operator 76 
equality-expression 76 
equivalence 
difference from C type 139, 166 
name 139, 166 
template type 345 
type 105, 139, 166 
error 
handling 355 
preprocessing directive 378 
ferror 378 
escape 
character — see backslash 
sequence 9 
sequence, difference from C 10 
sequence, undefined 9 
evaluation 
arguments to inline function, order of 102 
default argument 142 
difference from C expression 401 
expression 46 
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new, undefined order of 61 
of expression, order of 46 
order of argument 50 
undefined order of 46, 102 
undefined order of argument 50 
undefined order of function call 50 
evolution 
of C++ 1-2 
of C++ rationale 3, 403 
exact match, overloading resolution 
318-319 
example , 
*const 133 
_ cplusplus 120 
array 136 
casting 52, 67 
class declaration 172 
class object copy 298 
class object initialization 288 
const 133 
constant pointer 133 
constructor 266 
constructor and initialization 284 
declaration .14, 139 
declarator 131 
default argument 141-142 
definition 14 
delete 63, 283 
derived class 196 
destructor and delete 284 
ellipsis 140, 146 
enumeration 114 
explicit destructor call 278 
explicit qualification 203 
friend 168 
friend class 168 
friend function 248 
function declaration 140 
function definition 145 
fundamental type initialization 289 
jump past initialization 92 
linkage consistency 98 
local class 188 
local type name 189 
member function 173, 248 
member name access 244 
negative subscript 49 
nested class 185 
nested class declaration 187 
new 281 
overloaded assignment operator 335 
overloaded binary operator 333 
overloaded class member access operator 
337 
overloaded function call operator 335 
overloaded operator 335 
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overloaded subscripting operator 336 

overloaded unary operator 332 

overloading 307 

overloading resolution 313 

point of declaration 139 

pointer to member 135 

postfix ++ 54 

private copy constructor 287 

pure virtual function 214 

recursive function call 92 

reference 46 

scope of delete 284 

scope resolution operator 203 

sizeof class object 57 

sizeof reference 56 

sizeof type 41 

smart pointer 337 

static member 180 

subscripting 49, 136 

type name 131 

typedef 106, 132 

typedef class name 169 

unnamed argument 145 

user-defined conversion 273 

user-defined conversion ambiguity 288 

variable argument list 140, 146 

virtual base class with virtual function 234 

virtual destructor 277 

virtual function 208 

virtual function with virtual base class 234 
exception 

arithmetic 46 

handler 359 

handling 353-354 

handling, Murphy’s Law and 362 

handling, assumptions for 355 

handling constructor 358 

handling, debuggers and 358 

handling destructor 358 

handling efficiency 357 

handling rationale 354, 357 

handling syntax summary 399 

handling, type-safe 357 

implementation dependency arithmetic 46 

throwing 356 ; 
exception-declaration 354 
exception-specification 361 
exit from scope, destructor and 89 
exit() 19,21 
expansion macro — see macro expansion 
explanation, subscripting 136 
explicit 

constructor call 266 

destructor call 278-279 

destructor call example 278 

qualification example 203 


type conversion — see casting 
expression 45 
ambiguity, declaration versus 93 
assignment 79 
constant 81 
evaluation 46 
evaluation, difference from C 401 
order of evaluation of 46 
parenthesized 47 
postfix 48 
primary 47 
reference 46 
reference in 46 
statement 84 
syntax summary 388 
unary 54 
undefined 52-53 
expression 81 
expression-list 48 
expression-statement 84 
extension 
toC 1, 402-403 
to C anonymous union 402 
to C class 402 
to C const 402 
to C, dangerous 405 
to C declaration statement 402 
toC delete 402 
to C destructor 403 
to C, implementation dependency 405 
to C inline function 402 
to C memberwise assignment 403 
to C memberwise initialization 403 
to C multiple inheritance 403 
toC new 402 
to C overloading 402 
to C overloading delete 403 
to C overloading new 403 
to C pointer to member 403 
toC protected 403 
to C reference type 402 
to C single precision arithmetic 402 
to C type checking 402 
to C user-defined type 402 
to C, void* pointer type 402 
toC volatile 403 
extern 
declaration 13 
linkage of 98 
linkage specification 116, 119 
reference declaration 154 
restriction 98 
external linkage 18 
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F suffix 10 
f suffix 10 
fault tolerancy 355 
fet-body 145 
fct-specifier 99 
field 
declaration : 184 
unnamed 96 
file 5, 17 
inclusion 375-376 
inclusion, Classic C 384 
name #include, undefined 376 
name, Classic C implementation 
dependency #include 384 
name, implementation dependency 
#include 376 
scope 15 
_ FILE _ 378-379 
filename included 376 
float 
constant 10 
type 23 
type specifier 111 
<float.h> 7,28 
floating 
point accuracy, computation 35, 46 
point accuracy, difference fromC 46 
point arithmetic, single precision 33 
point constant 10 
point constant, type of 10 
point conversion, implementation 
dependency 33 
point conversion, safe 33 
point integer conversion 33, 40 
point integer conversion, implementation 
dependency 34 
point integer conversion, safe 34 
point limits 28 
point limits, implementation dependency 
28 
point type 23 
point type, alignment of 24 
point type, implementation dependency 
23 


point type, sizeof 24 
for 
scope of declaration in 88 
statement 87-88 
statement, continue in 88 
statement, declaration in 88 
form feed 9 
formal 
argument — see also argument 
argument initialization 49 
argument, scope of 15 
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forward 
class declaration 167, 196 
declaration 99 
free 
store — see also new, delete 
store and constructor anachronism 406 
store and destructor anachronism 406 
friend 
access specifier and 252 
class 249 
class access and 250 
class declaration 168 
class example 168 
class, scope of 168 
declaration, overloaded name and 249 
example 168 
function, access and 248 
function efficiency 248 
function example 248 
function, inline 251 
function, linkage of 251 
function, member function and 248 
function, nested class 187 
function summary of characteristics 306 
inheritance and 252 
member function 249 
member function declaration 175 
scope of 15 
specifier 108 
template and 350 
virtual and 209 
function 
— see also friend function, member 
function, inline function, virtual function 
argument — see argument 
body 145 
call 49 
call efficiency 118 
call evaluation, undefined order of 50 
call example, recursive 92 
call operator 49, 330 
call operator example, overloaded 335 
call operator, overloaded 335 
call operator summary of characteristics 
306 
call, recursive 51 
call, undefined 70 
cast, implementation dependency pointer 
to 69-70 
cast, pointer to 69 
comparison, pointer to 74 
conversion, difference from ANSI C 
pointer to 69 
conversion, pointer to 36 
declaration 13, 138 
declaration ambiguity 150 








426 Index 


declaration, difference from C 404 
declaration, ellipsis in 50, 138, 147 
declaration example 140 
declaration matching, overloaded 310 
declaration name hiding 144 
declaration, typedef 108 
declarator () 138 
definition 145 
definition 14, 18 
definition anachronism, C 406 
definition anachronism, old style 406 
definition example 145 
definition, scope of 18 
difference from C undeclared 50 
linkage specification 117 
linkage specification overloaded 117 
linkage specification pointer to 118 
member — see member function 
member declaration 173 
name decoding 125 
name encoding 122, 124 
name hiding 310 
name, overloaded 307 
operator 329 
overloaded — see also overloading 
pointer to 73 
pointer to member 71 
return — see return 
return type — see return type 
scope 15 
specifier 99 
summary of characteristics, inheritance of 
306 
template 345 
template declaration 346 
template definition 346 
type 24, 138 
virtual — see virtual function 
function-definition 145 
function-like macro 372 
fundamental 
type 22 
type conversion — see conversion, user- 
defined conversion 
type, copying 192 
type, destructor and 280 
type initialization example 289 
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generated 
constructor — see default constructor 
destructor — see default destructor 
global 
anonymous union 182 
anonymous union rationale 183 


name 15 
new 60 
new hiding 282 
object storage class 22 
goto 
difference from C initialization and 404 
initialization and 91 
statement 84, 89, 91 
grammar 387 
greater 
than operator 74 
than or equal to operator 74 


H 


handle — see catch 
handler, exception 359 
handler 354 
handler-list 354 
handling 
debuggers and exception 358 
exception — see exception handling 
headers 
ANSI C 7 
ANSI C and shared 120, 404 
library 7 
standard 7 
hex number 10 
hexadecimal constant 8 
hiding 
— see name hiding 
data 256 
global new 282 
information 256 
horizontal tab 9 
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identification, object type 212 
identifier 6, 48, 95 
_, underscore in 7 
implementation dependency case of 6 
implementation dependency length of 6 
name space 26 
identities and overloading, operator 331 
#if 377 
Classic C 385 
if statement 85 
tifdef 378, 385 
if-else ambiguity 85 
if-line 376 
#ifndef 378 
Classic C 385 
if-part 376 
implementation 


dependency tinclude 375, 384 
dependency #include file name 376 
dependency #include file name, Classic 
C 384 
dependency #include nesting limit 376 
dependency #include nesting limit, 
Classic C 384 
dependency #indef nesting limit 378 
dependency #indef nesting limit, Classic 
C 385 
dependency _STDC__ 379 
dependency alignment of bit-field 184 
dependency alignment requirement 23 
dependency allocation 173, 241 
dependency arguments to main() 19 
dependency arithmetic exception 46 
dependency asm 115 
dependency base class allocation 198 
dependency bit-field allocation 184-185 
dependency case of identifier 6 
dependency change to const object 71 
dependency char integer 32 
dependency conditional compilation 
nesting limit 378 
dependency conditional compilation 
nesting limit, Classic C 385 
dependency constructor and new 61 
dependency destruction of temporary 268 
dependency, difference from ANSI C 404 
dependency division 72 
dependency extension to C 405 
dependency floating point conversion 33 
dependency floating point integer 
conversion 34 
dependency floating point limits 28 
dependency floating point type 23 
dependency generation of temporary 267, 
299-301 
dependency integer conversion 33 
dependency integer demotion 33 
dependency integral limits 28 
dependency integral promotion 32, 322 
dependency left shift 74 
dependency length of identifier 6 
dependency linkage of main() 19 
dependency linkage specification 116 
dependency modulus 72 
dependency object linkage 118 
dependency overflow 46 
dependency pointer comparison 75 
dependency pointer integer conversion 
67-68 
dependency pointer subtraction 73 
dependency pointer to function cast 69-70 
dependency pragma 378 
dependency range of types 7 
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dependency rationale 11 

dependency right shift 74 

dependency sign of bit-field 184 
dependency sign of char 22-23 
dependency signed unsigned 33 
dependency sizeof enum 114 
dependency sizeof expression 58 
dependency sizeof integer type 33 
dependency sizeof integral type 23, 41 
dependency sizeof type 22 
dependency sizeof types 323 
dependency string literal 10, 37 
TA temporary and inline function 


dependency temporary as return value 
300 


dependency type of integer constant 8 

dependency type of ptrdiff t 73 

dependency type of size_t 58 

dependency type of sizeof expression 7 

dependency type of wchar t 10-11 

dependency value of char constant 10 

dependency value of multicharacter 
constant 9 

dependency value of union member 53 

dependency volatile 110 

efficiency, class 192 

limitations, inline 102 

of inheritance 217, 219 

of member function 177 

of member function call 176-177, 220 

of multiple inheritance 219, 225 

of pointer to member 158 

of pointer to member function 153 

of pointer to static member 158 

of virtual base class 225 

of virtual base class initialization 296 

of virtual base class with virtual function 
233 

of virtual function 227-228 

of virtual function call 209, 228-229 

of virtual function table 159, 229, 231 

of virtual function with virtual base class 
233 

rationale, class 191 

implicit 

constructor call 262, 271 

conversion 31, 47, 270 

destructor call 278 

user-defined conversion 274, 287 

#include 375-376 

Classic C 384 

filename 376 

file name, Classic C 384 

file name, Classic C implementation 
dependency 384 
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file name, Classic C token 384 
file name combining tokens 376 
file name combining tokens, Classic C 384 
file name, implementation dependency 
376 
file name, token 376 
implementation dependency 375, 384 
nesting limit, Classic C implementation 
dependency 384 
nesting limit, implementation dependency 
376 
syntax 375 
undefined file name 376 
included, filename 376 
inclusion 
source file 375-376 
source file, Classic C 384 
increment 
operator 53-54, 56 
operator, overloaded 338 
findef 
nesting limit, Classic C implementation 
dependency 385 
nesting limit, implementation dependency 
378 
indexing - see subscripting 
indirect base class 197-198 
indirection 55 
operator 54 
inequality operator 76 
information hiding 256 
inheritance 195-196 
— see also multiple inheritance 
and ambiguity 206 
and conversion 224 
and friend 252 
and pure virtual function 215 
and virtual function 232 
hierarchy, overloading resolution and 324 
implementation of 217, 219 
of constructor 263 
of destructor 277 
of function summary of characteristics 306 
of overloaded operator 330 
of user-defined conversion 273 
init-declarator 129 ; 
initialization 148, 285 
and goto 91 
and goto, difference from C 404 
and new 60, 288 
and temporary 286 
array 151 
array member 290 
array of class objects 152, 289 
assignment versus 80-81, 285-286 
auto 91-92 


auto object 149 

base class 290-291 

character array 153 

class member 150 

class object 151, 284 

class object — see also constructor 

const 108, 110, 149 

const array member 289-290 

const member 291 

const pointer 149 

constructor and 284 

default 150 

default constructor and 284 

definition and 98 

difference from ANSI C const 110 

difference from C jump past 92, 404 

dynamic 19 

example, class object 288 

example, constructor and 284 

example, fundamental type 289 

example, jump past 92 

extension to C memberwise 403 

formal argument 49 

implementation of virtual base class 296 

in block 91 

jump past 86, 91 

limitation, static object 19 

local object 22 

local static 92 

member 290, 296 

member object 291 

order of 19, 198 

order of base class 292 

order of member 292 

order of virtual base class 292-293 

overloaded assignment and 285 

pointer to const 149 

pointer to volatile 149 

programming technique, dynamic 20 

rationale 285 

rationale, base class 290 

rationale, member 181 

reference 38, 135, 153 

reference member 291 

register 91 

run-time 19 

static array member 289 

static member 180-181 

static object 19, 149-150 

struct 151 

syntax 148, 286-287 

union 152, 182 

virtual base class 293, 296 

volatile pointer 149 
initializer 149 

base class 145 


list (} 151 
member 145 
scope of member 294 
initializer 148 
initializer-list 148 
inline 
as optimization 101 
friend function 251 
function 99 
function efficiency 380 
function, extension to C 402 
function, implementation dependency 
temporary and 303 
function, linkage of 17, 98-99 
function, order of evaluation arguments to 
102 
function, temporary and 100 
implementation limitations 102 
member function 103, 178 
member function definition 18 
member function rationale 103 
member function rewriting rules 178 
rationale 103-104 
versus macro expansion 100 
virtual efficiency 209 
inline 
member function declaration 175 
specifier 99 
versus preprocessing macro 380 
instance 174 
instantiation, virtual function 232 
int 
default type 111 


type 23 

type specifier 111 
integer 

cast, pointer to 67 

constant 8 


constant, base of 8 

constant, implementation dependency type 
of 8 

constant, type of 8 

conversion 33, 41 

conversion, char 31 

conversion, floating point 33, 40 

conversion, implementation dependency 
33 

conversion, implementation dependency 
floating point 34 

conversion, implementation dependency 
pointer 67-68 

conversion, pointer to 72 

conversion, safe 33 

conversion, safe floating point 4 

conversion, signed unsigned 33 

demotion 33 
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demotion, implementation dependency 33 

implementation dependency char 32 

to pointer cast 68 

to pointer conversion 72 

type, implementation dependency sizeof 
33 


integral 

limits 28 

limits, implementation dependency 28 

promotion 31-32, 50 

promotion, Classic C and 32 

promotion compatibility 32 

promotion, implementation dependency 
32, 322 

type 24 


type, alignment of 23 
type, implementation dependency sizeof 


23, 41 

type, sizeof 23, 41-42 

value, undefined unrepresentable 33 
interface, class as 191 
interna] linkage 17 
interpretation 

of binary operator 333 

of unary operator 332 
iostream library 21 
ISO character set 371 
iteration statement 87 
iteration-statement 87, 89-90 
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Jennifer 182 
Jessie 271 
jump 
past initialization 86, 91 
past initialization, difference from C 92, 
404 
past initialization example 92 
statement 89 
jump-statement 89 
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Kernighan and Ritchie 1 
keyword 387 

anachronism, overload 405 

list 7 

rationale, static 180 
Koenig, Andrew 353, 355 
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L 
prefix 10-11 
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suffix 8, 10 
1 suffix 8, 10 
label 91 
case 84-86 
default 84-86 
name space 84 
scope of 15, 84 
specifier : 84 
labeled statement 84 
lattice — see DAG, class 
layout 
access specifier and object 241 
bit-field 184 
class object 173, 198, 217-220, 225 
compatibility with C object 165 
derived class 219-220 
padding object 57 
virtual base class 225 
virtual base class with virtual function 235 
Virtual function with virtual base class 235 
left 
shift, implementation dependency 7 
shift operator 74 
shift, undefined 74 
length x : 
of identifier, implementation dependency 
6 
of name 6 
less 
than operator 74 
than or equal to operator 74 
lexical conventions 5 
library 
headers 7 
iostream 21 
limits, implementation dependency integral 
28 
<limits.h> 7, 22, 28 
line 
continuation, backslash and 369-370 
continuation, preprocessing 370 
#line 378 
Classic C 385 
__LINE__ 378-379 
linkage 13, 17 
and portability 99 
compatibility with C 99 
consistency 18, 98 
consistency example 98 
consistency rationale 99 
difference from C 404 
external 18 
implementation dependency object 118 
internal 17 
limitations, type-safe 126 
of class 18 


of const 17, 98, 110 
of enumerator 18 
ofextern 98 
of friend function 251 
of inline function 17, 98-99 
of local name 18 
of main(), implementation dependency 
19 
of member function 18, 175 
of static 17, 98, 117 
of static member 18 
of template 18 
of typedef 18 
overloading and 121 
specification 116, 119-121 
specification class 117 
specification consistency 117 
specification, extern 116, 119 
specification function 117 
specification, implementation dependency 
116 
specification object 117-118 
specification overloaded function 117 
specification pointer to function 118 
specification rationale 119 
toC 116 
type-safe 121 
linkage-specification 116 
linkers 
and name encoding 124 
and overloaded function 125 
and static member 181 
and virtual function table 232 
list 
keyword 7 
operator 7, 329 
{}, initializer 151 
literal 8, 47 
concatenation, string 370 
implementation dependency string 10, 37 
literal 8 
local 
class declaration 188 
class example 188 
class member function 189 
class, member function in 179 
class restriction 189 
class restriction, static member 180 
class, scope of 188 
name, linkage of 18 
object constructor 22 
object destructor 22 
object initialization 22 
object, static 22 
object storage class 22 
scope 15 


static, destruction of 92 
static initialization 92 
type name 189 
type name example 189 
type name, scope of 189 
variable, destruction of 91 
logical 
AND operator 77 
AND operator, side effects and 77 
OR operator 77 
OR operator, side effects and 77 
negation operator 54, 56 
long 
constant 8 
double constant 10 
double type 23 
type 23 
type specifier 111 
typedef and 97 
Ivalue 25 
assignment and 79 
cast 69 
conversion 31 
modifiable 25 
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macro 
const versus preprocessing 380 
definition, preprocessing 372 
expansion, inline versus 100 
expansion preprocessing 370 
expansion, preprocessing 372, 375 
function-like 372 
inline versus preprocessing 380 
name, scope of 375 
names, predefined 379 
preprocessing 369 
preprocessing, Classic C 383 
replacement 381 


replacement, preprocessing rescanning 375 


replacement, rescanning 381 

syntax summary 397 
main() 19 

arguments to 19 


implementation dependency arguments to 


19 


implementation dependency linkage of 19 


return from 19, 21 
management anachronism, memory 406 
manual organization 2 
Marian 49 
meaning 
of const 109 
of declarator 131 
of static 98 


Index 431 


member 


- see also base class member 

access operator, overloaded 337 

access ambiguity 202 

access, base class 196 

access, class 53 

access efficiency 220 

access, protected 253 

access rationale, protected 254 

access, struct default 165 

access, union 53 

access, union default 165 

address of 156 

alignment of class 68 , 

allocation, access specifier and 242 

array 172 

assignment 296 

class object 171 

constructor order of execution 265 

declaration 169 

declaration, class 169 

declaration, static 13 

definition 174 

definition, static 180 

destructor order of execution 277 

enumerator 115 

example, static 180 

function, access control and special 304 

function and access control 261 

function and friend function 248 

function call, constructor and 294 

function call, destructor and 294 

function call efficiency 177 

function call, implementation of 176-177, 
220 

function call, undefined 176 

function, class 173 

function, const 177 

function, constructor and 267 

function declaration, friend 175 

function declaration, inline 175 

function declaration, static 175 

function declaration, virtual 175 

function definition 174-175, 178 

function definition, inline 18 

function, destructor and 278 

function encoding 123 

function example 173, 248 

function, friend 249 

function, implementation of 177 

function in local class 179 

function in nested class 179 

function, inline 103, 178 

function, linkage of 18, 175 

function, local class 189 

function, nested class 187 
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function, overloading resolution and 316 
function rationale, inline 103 

function rewriting rules, inline 178 
function, static 174, 179 

function summary of characteristics 306 
function summary, special 306 

function template 349 

function, union 181, 183 

function, volatile 177 


implementation of pointer to static 158 


initialization 290, 296 
initialization, const 291 
initialization, order of 292 
initialization rationale 181 
initialization, reference 291 
initialization, static 180-181 
initializer 145 
initializer, scope of 294 
linkage of static 18 
local class restriction, static 180 
name access 241 
name access example 244 
name, overloaded 170 
object initialization 291 
of class type restriction 289 
pointer to — see pointer to member 
pointer to static 25 
static 179 
static class 22 
storage class, class 22 
template and static 351 
type of static 55, 180 
use, static 180 
member-declaration 169 
member-declarator 169 
member-list 169 
memberwise 
assignment 334 
assignment, extension to C 403 
initialization, extension to C 403 
mem-initializer 291 
memory 
management — see also new, delete 
Management anachronism 406 
mapped I/O, optimization and 110 
mapped I/O, volatile and 110 
message 174 
meta class 212 
method 174 
missing 
storage class specifier 98 
type specifier 111 
ML 355 
modifiable lvalue 25 
modularity 165 
modulus 


implementation dependency 72 
operator 72 
most derived class 293 
multicharacter 
constant 9 
constant, implementation dependency 
value of 9 
multidimensional 
array 136 
array declarator 136 
multiple 
declaration 14, 18 
definition 14 
inheritance 195, 197 
inheritance DAG 198, 200-201, 204, 206 
inheritance and ambiguity 206 
inheritance and cast 221 
inheritance and conversion 223 
inheritance, extension to C 403 
inheritance, implementation of 219, 225 
inheritance programming technique 207 
multiplication operator 72 
multiplicative operator 72 
multiplicative-expression 72 
Murphy’s Law and exception handling 362 
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name 6, 13, 47 
address of qualified 55 
and translation unit 13 
class — see class name 
declaration 13, 96 
elaborated enum 112 
encoding, constructor 123 
encoding, destructor 123 
encoding, linkers and 124 
encoding, overloaded function 122, 124 
equivalence 139, 166 
global 15 
hiding 15-16, 27, 47-48, 91 
hiding, class declaration 166 
hiding, default argument and 142 
hiding, function 310 
hiding, function declaration 144 
hiding, overloading versus 310 
hiding, typedef 106 
hiding, user-defined conversion and 275 
length of 6 
linkage of local 18 
overloaded function 307 
overloaded member 170 
point of declaration 16 
qualified 48 
scope of 15 
space 26 


space, class name 26 
space, compatibility with C 167 
space compromise 26 
space, difference from C 26, 404 
space, identifier 26 
space, label 84 
space rationale 26 
space, type name 26 
space, typedef 106 
type - see type name 
name 47 
negation operator, logical 54, 56 
negative subscript example 49 
nested 
class anachronism, scope of 407 
class declaration 185 
class declaration example 187 
class, difference from C 186 
class example 185 
class friend function 187 
class member function 187 
class, member function in 179 
class qualified name 112 
class rationale 186 
class, scope of 185 
nesting 
limit, Classic C implementation 
dependency #include 384 
limit, Classic C implementation 
dependency #indef 385 
limit, Classic C implementation 
dependency conditional compilation 
385 
limit, implementation dependency 
tinclude 376 
limit, implementation dependency #indef 
378 
limit, implementation dependency 
conditional compilation 378 
new 37, 58-59, 280, 282, 285 
access and 282 
and array 283 
array 59 
array of class objects and 60 
constructor and 60-61, 262, 282 
default constructor and 61 
efficiency 60, 65 
example 281 
extension to C 402 
extension to C overloading 403 
global 60 
hiding, global 282 
implementation dependency constructor 
and 61 
initialization and 60, 288 
overloading 282 
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placement syntax 60 
private constructor and 305 
protected constructor and 305 
rationale, type of 281 
scope of 282 
scoping and 59 
storage allocation 58 
summary of characteristics 306 
type of 281 
undefined order of evaluation 61 
undefined value 60 
zero argument to 59 
<new.h> 7 
new-line 9 
new-type-name 58 
Nicholas 37 
nonnested class anachronism 407 
nonvirtual base class DAG 201 
notation, syntax 2 
null 
character 0 11 
pointer 35, 38, 74 
pointer conversion 36-37 
pointer dereference 176 
Preprocessing argument 381 
preprocessing argument, undefined 381 
preprocessing directive 379 
statement 84 
number 
hex 10 
octal 10 
numerical limits — see integral limits, 
floating point limits 
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object 13, 25 
class — see also class object 
complete 293 
constructor, local 22 
definition 14, 18 
destructor and placement of 279 
destructor, local 22 
destructor static 21 
initialization, auto 149 
initialization limitation, static 19 
initialization, local 22 
initialization, static 19, 149-150 
layout, access specifier and 241 
layout, compatibility with C 165 
layout, padding 57 
linkage, implementation dependency 118 
linkage specification 117-118 
reference versus 153 
static local 22 
storage class, global 22 
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storage class, local 22 

temporary — see temporary 

type identification 212 

undefined deleted 63 

unnamed 266 
object-oriented programming 209 
octal 

constant 8 

number 10 
old 

style base class initializer anachronism 406 

style function definition anachronism 406 
one’s 

complement operator 54, 56 

complement operator ambiguity, 

destructor versus 279 

operand 

const 46 

reference 46 

volatile 46 
operations on class object 164 
operator 

# preprocessing 373, 382 

## preprocessing 374, 382 

t= 79 

&= 79 

t= 79 


^= 79 

additive 72 

address-of 54 

assignment 79, 285, 295 
bitwise 76 

bitwise AND 76 

bitwise exclusive OR 77 
bitwise inclusive OR 77 
cast 54, 67, 130 

class member access 53 
comma 81 

conditional expression 78 
conversion 47, 272 
decrement 54, 56 

default assignment 334 
defined 377 

delete — see delete 
division 72 

equality 76 

example, scope resolution 203 
function call 49, 330 
function call 330 
function summary of characteristics 306 
greater than 74 


greater than or equal to 74 
identities and overloading 331 
increment 53-54, 56 
indirection 54 
inequality 76 
left shift - see left shift operator 
less than 74 
less than or equal to 74 
list 7, 329 
logical AND 77 
logical OR 77 
logical negation 54, 56 
modulus 72 
multiplication 72 
multiplicative 72 
new — see new 
one’s complement 54, 56 
overloaded 45 
overloading — see also overloaded 
operator 
overloading rationale 330 
overloading restrictions 330 
pointer to member 71 
precedence of 46 
relational 74 
right shift; right shift operator 74 
scope resolution 15, 47-48, 174, 196, 209 
shift — see left shift operator, right shift 
operator 
side effects and comma 81 
side effects and logical AND 77 
side effects and logical OR 77 
sizeof 54, 56 
subscripting 49, 330 
unary 54 
unary minus 54, 56 
unary plus 54, 56 
use, scope resolution 180 
used with class name, scope resolution 16 
|= 79 
operator 
function 329 
overloaded 329 
operator 329 
operator-function-name 329 
optimization 
and memory mapped I/O 110 
and signals 110 
inline as 101 
of temporary — see elimination of 
temporary 
OR 
operator, bitwise exclusive 77 
operator, bitwise inclusive 77 
operator, logical 77 
operator, side effects and logical 77 
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of argument evaluation 50 
of argument evaluation, undefined 50 
of base class initialization 292 
of evaluation arguments to inline function 
102 
of evaluation new, undefined 61 
of evaluation of expression 46 
of evaluation, undefined 46, 102 
of execution, base class constructor 265 
of execution, base class destructor 277 
of execution, constructor and array 265 
of execution, constructor and static 
objects 289 
of execution, destructor 277 
of execution, destructor and array 277 
of execution, destructor and static 
objects 289 
of execution, member constructor 265 
of execution, member destructor 277 
of function call evaluation, undefined 50 
of initialization 19, 198 
of member initialization 292 
of virtual base class initialization 292-293 
organization, manual 2 
out of range value, undefined conversion 
33 
overflow 46 
implementation dependency 46 
overload keyword anachronism 405 
overloaded 
assignment and initialization 285 
assignment efficiency 192 
assignment operator 334 
assignment operator example 335 
binary operator 333 
binary operator example 333 
class member access operator example 337 
decrement operator 338 
function, address of 55, 327 
function ambiguity detection 312 
function and standard conversion 326 
function call operator 335 
function call operator example 335 
function call resolution — see also 
argument matching, overloading 
resolution 
function, debuggers and 125 
function declaration matching 310 
function, linkage specification 117 
function, linkers and 125 
function name 307 
function name 121 
function name encoding 122, 124 
increment operator 338 
member access operator 337 
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member name 170 

name and access declaration 246 

name and friend declaration 249 

operator 329 

operator 45 

operator 329 

operator and default argument 331 

operator example 335 

operator, inheritance of 330 

subscripting operator 336 

subscripting operator example 336 

unary operator 332 

unary operator example 332 
overloading 138, 166, 307 

C function 121 

and access 312 

and const 308 

and default argument 144 

and delete 283 

and derived class 310 

and enum 309 

and linkage 121 

and pointer 308 

and pointer versus array 309 

and reference 307 

and return type 308 

and scope 310 

and scope rationale 311 

and static 309 

and typedef 309 

and volatile 308 

delete, extension toC 403 

example 307 

extension toC 402 

new 282 

new, extension to C 403 

operator identities and 331 

postfix ++ and -- 338 

prefix ++ and -- 338 

resolution 312-313 

resolution ambiguity 313 

resolution and access contro] 203 

resolution and conversion 317 

resolution and default argument 316 

resolution and ellipsis 317, 319, 325 

resolution and ellipsis ambiguity 325 

resolution and inheritance hierarchy 324 

resolution and member function 316 

resolution and pointer conversion 324, 328 

resolution and pointer conversion rationale 

329 

resolution and promotion 318, 321 

resolution and reference conversion 324 

resolution and standard conversion 318, 

322 
resolution and temporary 323 
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resolution and user-defined conversion 
319, 325-326 

resolution and zero 324 

resolution conversion and ambiguity 313 

resolution exact match 318-319 

resolution example 313 

resolution rationale 319-322, 325 

resolution rules 318 

resolution, template function 345 

resolution trivial conversions 318 

restriction 330 

versus name hiding 310 

overriding 
virtual function 208 
virtual function rationale 210 
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padding object layout 57 
parameter — see argument 
parameterized type ~ see template 
parentheses 
and ambiguity 62 
in declaration 131-132 
parenthesized expression 47 
partially specified class 175 
performance — see efficiency 
persistence of temporary 268-269 
phases 
preprocessing 370 
translation 5 
placement 58 
of object, destructor and 279 
syntax, new 60 
pm-expression 71 
point 
of declaration class name 168 
of declaration enumerator 17 
of declaration example 139 
of declaration name 16 
of definition, enumerator 114 
pointer 
— see also void* 
argument 145 
arithmetic 72 
assignment, const 79 
assignment to 79 
assignment, volatile 79 
cast, integer to 68 
comparison 74-75 
comparison and portability 75 
comparison base class 222 
comparison derived class 222 
comparison, implementation dependency 
75 


comparison, undefined 73, 75 


comparison, void* 74 

conversion 35 

conversion 37 

conversion, ANSI C and 36 

conversion ambiguity 36 

conversion, array 36 

conversion, base class 36 

conversion, const 37 

conversion, derived class 36 

conversion, integer to 72 

conversion, null 36-37 

conversion, overloading resolution and 
324, 328 

conversion rationale, overloading 
resolution and 329 

conversion, void* 36 

conversion, volatile 37 

conversion, zero 36 

declaration 133 

declarator * 132 

delete zero 63 

dereference, null 176 

example, constant 133 

initialization, const 149 

initialization, volatile 149 

integer conversion, implementation 
dependency 67-68 

null 35, 38, 74 

overloading and 308 

subtraction 73 

subtraction, implementation dependency 
73 

terminology 25 

to abstract class 214 

to base class conversion 212 

to bit-field restriction 184 

to const assignment 79 

to const initialization 149 

to constructor programming technique 
266 

to derived class conversion 212 

to function 73 

to function cast 69 

to function cast, implementation 
dependency 69-70 

to function comparison 74 

to function conversion 36 

to function conversion, difference from 
ANSI C 69 

to function, linkage specification 118 

to integer cast 67 

to integer conversion 72 

to member 25, 71, 155 

to member anachronism, cast of 407 

to member and void* 70 

to member, assignment 80 


to member, assignment to 79 
to member cast 70 
to member conversion 38-39 
to member conversion ambiguity 39 
to member conversion anachronism 407 
to member declarator :;* 135 
to member example 135 
to member, extension to C 403 
to member function 71 
to member function, implementation of 
158 
to member function, undefined bound 407 
to member, implementation of 158 
to member operator 71 
to member rationale 55 
to member syntax 156 
to member void* conversion 40 
to member, zero assignment to 79 
to pointer cast 68 
to pointer conversion 72 
to static member 25 
to static member, implementation of 
158 
to volatile assignment 79 
to volatile casting 71 
to volatile initialization 149 
type 24 
type extension to C, void* 402 
versus array, overloading and 309 
zero 35, 38, 74 
zero assignment to 79 
polymorphism 209 
portability 3, 11, 120 
linkage and 99 
pointer comparison and 75 
postfix 
++ and -- 53 
++ and --, overloading 338 
++ example 54 
expression 48 
pragma preprocessing directive 378 
#pragma 378 
pragma, implementation dependency 378 
precedence of operator 46 
predefined macro names 379 
prefix 
++ and -- 56 
++ and --, overloading 338 
L 10-11 
preprocessing 5, 369 
ANSI C 380 
Classic C 380 
Classic C macro 383 
Reiser model 380 
and C 5, 370 
argument, null 381 
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argument, tokenless 381 
argument, undefined null 381 
argument, undefined tokenless 381 
character constant 370 
character-based 380 
comment 370 
comment, Classic C 384 
compatibility 380 
concatenation 382 
conditional compilation 383 
directive 369 
directive, error 378 
directive, null 379 
directive, pragma 378 
line continuation 370 
macro 369 
macro, const versus 380 
macro definition 372 
macro expansion 372, 375 
macro expansion 370 
macro, inline versus 380 
operator, € 373, 382 
operator, ## 374, 382 
phases 370 
rescanning macro replacement 375 
syntax summary 397 
token 370 
token 369 
token-based 380 
primary expression 47 
private 239 
base class 242 
constructor 304 
constructor and new 305 
copy constructor example 287 
destructor 305 
destructor and delete 305 
program 5, 17 
environment 19 
start 19 
termination 19, 21 
termination and destructor 278 
programming 
object-oriented 209 
technique, dynamic initialization 20 
technique, multiple inheritance 207 
technique, pointer to constructor 266 
technique, virtual base class 201 
technique, virtual constructor 262 
prohibiting 
assignment 304 
copying 304 
promotion 
Classic C and integral 32 
compatibility, integral 32 
implementation dependency integral 32, 
322 
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integral 31-32, 50 
overloading resolution and 318, 321 
value-preserving 32 
protectéd 239 
constructor 304 
constructor and new 305 
destructor 305 
destructor and delete 305 
extension to C 403 
member access 253 
member access rationale 254 
protection 
— see access control 
unit of 256 
ptrdiff t 73 
implementation dependency type of 73 
plr-operator 130 
public 239 
base class 242 
punctuators 7 
pure 
specifier 169 
virtual function 214 
virtual function call, undefined 215, 295 
virtual function definition 214 
virtual function example 214 
virtual function, inheritance and 215 
virtual function rationale 215 
pure-specifier 169 
purpose of constructor 262 
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qualified 

name 48 

name, address of 55 

name, nested class 112 
qualified-class-name 112 
qualified-name 48 
qualified-type-name 112 
question mark 9 
questionably signed result 32 
quote 

double 9 

single 9 
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raise — see throw 

Randel, Brian 355 

range of types, implementation dependency 
7 


rationale 
access control 239, 256-258 
adjusting access 246-247 


array of class objects 60 
assignment to base class 297 
base class initialization 290 
class declaration 174 
class implementation 191 
const reference 155 
constructor restriction 265 
copy constructor 264 
declarator syntax 132 
default argument 144 
destructor 276, 278 
evolution of C++ 3, 403 
exception handling 354, 357 
global anonymous union 183 
implementation dependency 11 
initialization 285 
inline 103-104 
inline member function 103 
linkage consistency 99 
linkage specification 119 
member initialization 181 
name space 26 
nested class 186 
operator overloading 330 
overloading and scope 311 
overloading resolution 319-322, 325 
overloading resolution and pointer 
conversion 329 
overriding virtual function 210 
pointer to member 55 
protected member access 254 
pure virtual function 215 
reference 153 
scoping difference from C 402 
static keyword 180 
template 342, 344, 347 
type name redefinition 190 
type of delete 281 
type of new 281 
union 181-182 
readonly memory, undefined 109 
recursive 
function call 51 
function call example 92 
redefinition 
class name 189 
enumerator 114 
rationale, type name 190 
typedef 106, 189 
reference 24 
address of 56 
and argument passing 154 
and return 154 
and temporary 154 
argument 49, 134, 145 
argument, const 308 


array of 154 

assignment 154 

assignment to 80 

call by 49 

cast 69 

const 154 

conversion 38 

conversion ambiguity 38 

conversion, overloading resolution and 

324 

declaration 134 

declaration, extern 154 

declarator & 134 

efficiency 154 

example 46 

example, sizeof 56 

expression 46 

in expression 46 

initialization 38, 135, 153 

member initialization 291 

operand 46 

overloading and 307 

rationale 153 

rationale, const 155 

restriction 135 

temporary, scope of 155 

to base class 38 

type, extension to C 402 

versus object 153 

volatile 155 
register 

declaration 97 

declarator 97 

efficiency 103 

initialization 91 

restriction 97 

storage class 97 

variable 177 
Reiser model, preprocessing 380 
relational operator 74 
relational-expression 74 
release, resource acquisition and 358 
remainder operator — see modulus operator 
renaming virtual function 236 
reraise 358 
rescanning 

macro replacement 381 

macro replacement, preprocessing 375 
reserved 

identifier 7 

word — see keyword 
resolution 

overloading — see overloading resolution 

scoping ambiguity 203 

template function overloading 345 
resource acquisition and release 358 
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restriction 
address of bit-field 184 
alignment 68 
anonymous union 183 
auto 97 
bit-field 184 
constructor 262, 265 
declaration statement 85, 87 
default assignment operator 296 
default copy constructor 296 
destructor 276, 278 
enumerator 113 
extern 98 
local class 189 
member of class type 289 
overloading 330 
pointer to bit-field 184 
rationale, constructor 265 
reference 135 
register 97 
static 98 
static member local class 180 
union 181-182, 265 
restrictions, operator overloading 330 
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return 
type 138 
type, class object 51, 288 
type conversion 90 
type, overloading and 308 
value, implementation dependency 
temporary as 300 
value, temporary as 300 
return 89-90 
constructor and 90 
from main() 19, 21 
reference and 154 
statement — see also return 


439 


rewriting rules, inline member function 178 


right 
shift, implementation dependency 74 
shift operator 74 
shift operator efficiency 74 

Ritchie, Kernighan and 1 

rounding 34 


rules 


arithmetic conversion 40 

inline member function rewriting 178 
overloading resolution 318 
summary, scope 216 

type conversion 34 


run-time initialization 19 
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safe 
conversion 40 
floating point conversion 33 
floating point integer conversion 34 
integer conversion 33 
Schwarz, Gerald 21 
scope 13, 26 
class 15 
destructor and exit from 89 
difference from C 401 
file 15 
function 15 
local 15 
of argument declaration 143 
of class declaration 166 
of class name 166 
of declaration in for 88 
of declaration list 144 
of default argument 142 
of delete example 284 
of enumerator class 115 
of formal argument 15 
of friend 15 
of friend class 168 
of function definition 18 
of label 15, 84 
of local class 188 
of local type name 189 
of macro name 375 
of member initializer 294 
of name 15 
of nested class 185 
of nested class anachronism 407 
of new 282 
of reference temporary 155 
of type name 191 
overloading and 310 
rationale, overloading and 311 
resolution operator 15, 47-48, 174, 196, 
209 
resolution operator example 203 
resolution operator use 180 


resolution operator used with class name 


16 

rules summary 216 
scoping 

ambiguity resolution 203 

and new 59 

difference from C rationale 402 
selection statement 85 
selection-statement 85 
self 176 
semantics, class member 53 
sequence, statement 83 


sequencing operator — see comma operator 


set_new_handler() 280 
setterminate() 364 
setunexpected() 365 
shared headers, ANSI C and 120, 404 
shift operator - see left shift operator, right 
shift operator 
shift-expression 74 
short 
type 23 
type specifier 111 
typedef and 97 
side 
effects 46 
effects and comma operator 81 
effects and constructor 267 
effects and destructor 267 
effects and logical AND operator 77 
effects and logical OR operator 77 
effects and temporary 267 
sign 
of bit-field efficiency 184 
of bit-field, implementation dependency 
184 


of char efficiency 23 
of char, implementation dependency 
22-23 
signal — see throw 
signals 
optimization and 110 
volatile and 110 
Signed 
char type 22 
character 22 
conversion 33 
typedef and 97 
unsigned, implementation dependency 
unsigned integer conversion 33 
simple-type-name 111 
Simula 149, 153, 191, 197 
single 
inheritance — see inheritance 
precision arithmetic, extension to C 402 
precision floating point arithmetic 33 
quote 9 
sizeof 
array 58 
character constant 9 
class object 57 
class object example 57 
difference from C 401 
empty class 164 
enum 114 
enum, implementation dependency 114 
expression, implementation dependency 
58 
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expression, implementation dependency 
type of 7 

floating point type 24 

integer type, implementation dependency 
33 


integral type 23, 41-42 
integral type, implementation dependency 
23, 41 
operator 54, 56 
reference example 56 
string 11 
type efficiency 42 
type example 41 
type, implementation dependency 22 
types, implementation dependency 323 
size_t 58 
implementation dependency type of 58 
Smalltalk 174, 176 
smart pointer example 337 
source 
file 5 
file, Classic C inclusion 384 
file, inclusion 375-376 
file inclusion 376 
file inclusion, Classic C 384 
special 
member function — see also constructor, 
destructor, inline function, user-defined 
conversion, virtual function 
member function, access control and 304 
member function summary 306 
specifier 
access — see access specifier 
auto 97 
declaration 96 
friend 108 
function 99 
inline 99 
missing storage class 98 
static 97 
storage class 97 
template 108 
type - see type specifier 
typedef 105 
virtual 105 
stack unwinding 358 
standard 
conversion 31 
conversion, overloaded function and 326 
conversion, overloading resolution and 
318, 322 
headers 7 
start, program 19 
statement 83 
— see also return, return 
break 89 
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compound 84 
continue 89-90 
continue in for 88 
declaration 83, 91 
declaration in for 88 
declaration in switch 86 
do 87 
empty 84 
expression 84 
extension to C declaration 402 
for 87-88 
goto 84, 89, 91 
if 85 
iteration 87 
jump 89 
labeled 84 
null 84 
restriction, declaration 85, 87 
selection 85 
sequence 83 
switch 85, 89 
syntax summary 396 
while 87 
(}, block 84 

statement 83 

static 
array member initialization 289 
class member 22 
destruction of local 92 
initialization, local 92 
keyword rationale 180 
linkage of 17, 98, 117 
local object 22 
meaning of 98 
member 179 
member declaration 13 
member definition 180 
member example 180 
member function 174, 179 
member function declaration 175 
member, implementation of pointer to 158 
member initialization 180-181 
member, linkage of 18 
member, linkers and 181 
member local class restriction 180 
member, pointer to 25 
member, template and 351 
member, type of 55, 180 
member use 180 
object, destructor 21 
object initialization 19, 149-150 
object initialization limitation 19 
objects order of execution, constructor and 

289 
objects order of execution, destructor and 
289 
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overloading and 309 

restriction 98 

specifier 97 

storage class 21 

variable, template and 351 
<stdarg.h> 138, 146 
__STpDC__ 379 

implementation dependency 379 
<stddef.h> 7, 10-11, 58 
<stdlib.h> 7,19, 21 
storage 

allocation new 58 

class 13, 21 

class, auto 21 

class, class member 22 

class, const object 110 

class declaration 97 

class, global object 22 

class, local object 22 

class register 97 

class specifier 97 

class specifier, missing 98 

class, static 21 

management — see new, delete 

of array 137 
string 

concatenation 10 

constant 10 

distinct 10 

literal 10 

literal concatenation 370 

literal concatenation, undefined 11 

literal, difference from C 11 


literal, implementation dependency 10, 37 


literal, type of 10 
literal, undefined change to 10 
sizeof 11 
terminator 0 11 
type of 10 
wide-character 11 
stringizing 382 
struct 24 
class versus 165 
default member access 165 
initialization 151 
type specifier 111 
structure 24 
tag — see class name 
subclass 197 
subscript example, negative 49 
subscripting 
example 49, 136 
explanation 136 
operator 49, 330 


operator example, overloaded 336 


operator, overloaded 336 


operator summary of characteristics 306 
subtraction 
implementation dependency pointer 73 
operator 72 
pointer 73 
suffix 
E 10 
F 10 
L 8,10 
U8 
f 10 
1 8,10 
u 8 
summary 
class declaration syntax 395 
compatibility with ANSI C 403 
compatibility with C 401 
declaration syntax 391 
declarator syntax 393 
exception handling syntax 399 
expression syntax 388 
macro syntax 397 
preprocessing syntax 397 
scope rules 216 
special member function 306 
statement syntax 396 
syntax 387 
template syntax 398 
superclass 197 
switch 
statement 85, 89 
statement, declaration in 86 
synonym, type name as 105 
syntax 
#include 375 
class member 53 
initialization 148, 286-287 
notation 2 
pointer to member 156 
rationale, declarator 132 
summary 387 
summary, class declaration 395 
summary, declaration 391 
summary, declarator 393 
summary, exception handling 399 
summary, expression 388 
summary, macro 397 
summary, preprocessing 397 
summary, statement 396 
summary, template 398 
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and static variable 351 
class 343 
class declaration 347 
class definition 347-348 
declaration 347 
efficiency 342 
function 345 
function declaration 347 
function definition 347-348 
function overloading resolution 345 
linkage of 18 
member function 349 
rationale 342, 344, 347 
syntax summary 398 
type equivalence 345 
template 342 
specifier 108 
template-arg 343 
template-arg-list 343 
template-argument 342 
template-argument-list 342 
template-class-name 343 
template-declaration 342 
temporary 267 
and inline function 100 
and inline function, implementation 
dependency 303 
and user-defined assignment operator 301 
argument 308 
as return value 300 
as return value, implementation 
dependency 300 
constructor for 267 
destructor for 267 
efficiency, destruction of 268 
elimination of 267, 299-301, 303 
implementation dependency destruction of 
268 
implementation dependency generation of 
267, 299-301 
initialization and 286 
overloading resolution and 323 
persistence of 268-269 
reference and 154 
scope of reference 155 
side effects and 267 
terminate () 364-365 
termination 
and destructor, program 278 
program 19, 21 
terminator 0, string 11 
terminology, pointer 25 
this 47,177 
anachronism, assignment to 406 
and constructor anachronism 406 
and destructor anachronism 406 
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and thunk 231 
and virtual function 229 
pointer - see this 
type of 177 
throw 354-355 
throw-expression 354 
type of 354 
throwing, exception 356 
throw-point 334 
thunk, this and 231 
A TIME e379 
token 5,7, 370 
include file name 376 
#include file name, ClassicC 384 
Preprocessing 369 
Preprocessing 370 
replacement — see macro expansion 
replacement, Classic C 383 
token-based preprocessing 380 
tokenless 
preprocessing argument 381 
preprocessing argument, undefined 381 
tolerancy, fault 355 
trailing tokens, #else and #endif 383 
translation 
phases 5 
unit 5 
unit and consistency 404 
unit, name and 13 
trigraph 370-371 
trivial conversions, overloading resolution 
318 
truncation 34 
try 354 
try-block 354 
type 13 
~ see also class, user-defined 
ambiguity, declaration 96 
arithmetic 24 
array 24 
char 22 
checking, argument 49 
checking, default argument 142 
checking, extension to C 402 
class and 163 
const 108 
conversion — see also conversion 
conversion, argument 270 
conversion, explicit — see casting 
conversion rules 34 
copying fundamental 192 
vie user-defined 192 
declaration 131 
declaration, class name as 166 
declaration consistency 18 
declaration, typedef as 105 
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double 23 

efficiency, sizeof 42 

equivalence 105, 139, 166 

equivalence, difference from C 139, 166 

equivalence, template 345 

example, sizeof 41 

extension to C reference 402 

extension to C user-defined 402 

float 23 

function 24, 138 

fundamental 22 

generator — see template 

identification, object 212 

implementation dependency sizeof 22 

int 23 

int, default 111 

long 23 

long double 23 

name 25, 130 

Name as synonym 105 

name example 131 

name example, local 189 

name, local 189 

name name space 26 

name redefinition rationale 190 

name, scope of 191 

name, scope of local 189 

of bit-field 184-185 

of character constant 9 

of class member 55 

of constructor 265 

of conversion 273 

of delete 283 

of delete rationale 281 

of enum 113-114 

of floating point constant 10 

of integer constant 8 

of integer constant, implementation 
dependency 8 

of new 281 

of new rationale 281 

of ptrdiff_t, implementation 
dependency 73 

of size_t, implementation dependency 
58 

of sizeof expression, implementation 
dependency 7 

of static member 55, 180 

of string 10 

of string literal 10 

ofthis 177 

of throw-expression 354 

of virtual function 208 

of wchar _t, implementation dependency 
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of zero 324 
pointer 24 
short 23 
signed char 22 
specifier, char 111 
specifier, class 111 
specifier, double 111 
specifier, enum 111 
specifier, float 111 
specifier, int 111 
specifier, long 111 
specifier, missing 11 
specifier, short 111 
specifier, struct 111 
specifier, union 111 
specifier, unsigned 111 
specifier, void 111 
specifier, volatile 110 
unsigned 23 
unsigned char 22 
user-defined 165 
void 24 
void* 25 
volatile 108 
type-argument 342 
typedef 25 
and long 97 
and short 97 
and signed 97 
and unsigned 97 
as type declaration 105 
class name 106-107, 169 
class name example 169 
declaration 14 
enumeration 107 
example 106, 132 
function declaration 108 
linkage of 18 
name hiding 106 
name space 106 
overloading and 309 
redefinition 106, 189 
specifier 105 
typedef-name 105 
type-list 362 
type-name 130 
types 
floating — see floating point,type 
implementation dependency range of 7 
implementation dependency sizeof 323 
integral — see integral type 
type-safe 
exception handling 357 
linkage 121 
linkage limitations 126 
type-specifier 108 
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` U suffix 8 


u suffix 8 
unary 
expression 54 
minus operator 54, 56 
operator 54 
operator example, overloaded 332 
operator, interpretation of 332 
operator, overloaded 332 
Plus operator 54, 56 
unary-expression 54 
unary-operator 54 
undeclared function, difference from C 50 
fundef 375, 377 
Classic C 384 
directive 379 
undefined 
access outside array bound 73, 76, 172 
argument to constructor 61 
bound pointer to member function 407 
change to const object 109 
change to string literal 10 
class, cast to 68 
conversion out of range value 33 
delete 63, 65 
deleted object 63 
destructor call 92 
division by zero 46, 72 
escape sequence 9 
expression 52-53 
file name #include 376 
function cal] 70 
left shift 74 
member function call 176 
null preprocessing argument 381 
order of argument evaluation 50 
order of evaluation 46, 102 
order of evaluation new 61 
order of function call evaluation 50 
pointer comparison 73, 75 
pure virtual function call 215, 295 
readonly memory 109 
string literal concatenation 11 
tokenless preprocessing argument 381 
uninitialized variable 150 
unrepresentable integral value 33 
value 61, 73 
value delete 63 
value new 60 
underscore 
character 6 
in identifier 7 
unexpected() 365 
uninitialized variable, undefined 150 
union 24, 181 
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access control, anonymous 183 
anonymous 182 
class versus 165 
constructor 181 
default member access 165 
destructor 181 
extension toC anonymous 402 
global anonymous 182 
initialization 152, 182 
member access 53 
member function 181, 183 
member, implementation dependency 
value of 53 
member, value of 53 
rationale 181-182 
rationale, global anonymous 183 
restriction 181-182, 265 
restriction, anonymous 183 
type specifier 111 
unit of protection 256 
unknown argument type 138 
unnamed 
argument 140 
argument example 145 
bit-field 184 -~ 
class 164 
class use 164 
field 96 
object 266 
unrepresentable integral value, undefined 
33 
unsigned 
arithmetic 23 
char type 22 
constant 8 
conversion 33 
implementation dependency signed 33 
integer conversion, signed 33 
type 23 
type specifier 111 
typedef and 97 
unwinding, stack 358 
user-defined 
assignment operator, efficiency and 301 
assignment operator, temporary and 301 
conversion 47, 270-272 
conversion ambiguity 275 
conversion ambiguity example 288 
conversion and name hiding 275 
conversion example 273 
conversion, implicit 274, 287 
conversion, inheritance of 273 
conversion, overloading resolution and 
319, 325-326 
conversion, virtual 274 
type 165 
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type — see also class 

type, access control and copying 304 
type, copying 192 

type, extension to C 402 


V 


va_arg() 146 
va_end() 146 
va_list 146 
value 
call by 49 
delete, undefined 63 
new, undefined 60 
of char constant, implementation 
dependency 10 
of enumerator 113 
of multicharacter constant, implementation 
dependency 9 
of union member 53 
of union member, implementation 
dependency 53 
undefined 61, 73 
undefined conversion out of range 33 
undefined unrepresentable integral 33 
value-preserving promotion 32 
variable 
argument list 50, 138, 146-147 
argument list efficiency 118 
argument list example 140, 146 
template and static 351 
undefined uninitialized 150 
va_start() 146 
VAX, conversion 41 
vertical tab 9 
virtual 
base class 200 
base class DAG 200-201, 204, 206, 292 
base class and cast 227 
base class, constructor and 262 
base class dominance 204 
base class example, virtual function with 
234 
base class, implementation of 225 
base class, implementation of virtual 
function with 233 
base class initialization 293, 296 
base class initialization, implementation of 
296 
base class initialization, order of 292-293 
base class layout 225 
base class layout, virtual function with 
235 


base class programming technique 201 

base class, virtual function table with 235 

base class with virtual function example 
234 


base class with virtual function, 
implementation of 233 

base class with virtual function layout 235 

constructor programming technique 262 

destructor 277 

destructor efficiency 278 

destructor example 277 

efficiency, inline 209 

function 208, 262 

function access 255 

function, base class and 232 

function call 209 

function call, constructor and 294 

function call, destructor and 294 

function call efficiency 209 

function call, implementation of 209, 
228-229 

function call, undefined pure 215, 295 

function, constructor and 232 

function definition 209 

function definition, pure 214 

function example 208 

function example, pure 214 

function example, virtual base class with 
234 

function, implementation of 227-228 

function, implementation of virtual base 
class with 233 

function, inheritance and 232 

function, inheritance and pure 215 

function instantiation 232 

function layout, virtual base č iss with 
235 

function, overriding 208 

function, pure 214 

function rationale, overriding 210 

function rationale, pure 215 

function, renaming 236 

function summary of characteristics 306 

function table, constructor and 262 

function table, implementation of 159, 229, 
231 

function table, linkers and 232 

function table with virtual base class 235 

function, this and 229 

function, type of 208 

function with virtual base class example 
234 

function with virtual base class, 
implementation of 233 

function with virtual base class layout 235 

user-defined conversion 274 

virtual 

and friend 209 

member function declaration 175 

specifier 105 
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void 
argument 138 
type 24 
type specifier 111 

voids 134 

void* 
conversion, difference from C 36 
conversion, pointer to member 40 
pointer comparison 74 
pointer conversion 36 
pointer to member and 70 
pointer type extension to C 402 
type 25 

volatile 
and memory mapped I/O 110 
and signals 110 
array 111 
assignment, pointer to 79 
casting, pointer to 71 
class object 111 
constructor and 178, 262 
declarator 133 
destructor and 178, 277 
extension to C 403 
implementation dependency 110 
initialization, pointer to 149 
member function 177 
operand 46 
overloading and 308 
pointer assis” ment 79 
pointer conversion 37 
pointer initialization 149 
reference 155 
type 108 
type specifier 110 

vptx — see implementation of virtual 

function 
ytbl — see virtual function table 
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wehar_ t 10-11 

implementation dependency type of 
10-11 

while statement 87 

white space 5 

wide-character 10 

string 11 


X 


x (X&) — see copy constructor 
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Zeto 
argument to new 59 
assignment to pointer 79 
assignment to pointer to member 79 
overloading resolution and 324 
pointer 35, 38, 74 
pointer conversion 36 
pointer, delete 63 
pointer dereference 176 
type of 324 
undefined ‘division by 46, 72 
width of bit-field 184 
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